Closed LonelyCat124 closed 2 months ago
The immediate workaround for this is to run with -fflow 0
. The main cost is that you can't use SCR, but it avoids a number of pernicious bugs like this one that are unlikely to get fixed any time soon.
Ok, that works - is there a way to get Regent to do a "preprocessing" type thing (like -fpretty 1
) that generates Regent code that can be read by the Regent parser? I'd like to see if this is happens with the same code without the metaprogramming or not, but would prefer to not have to rewrite the code entirely.
Oh, this can definitely happen without metaprogramming. The conditions that trigger it are having two regions of the same type that Regent cannot prove to be disjoint, in combination with accessing those regions later on in the body of the task. It's a long outstanding bug in RDIR that is a result of design decisions that are difficult to change at this point.
I've been thinking about making Regent assume that interfering region requirements are disjoint---which would be like the constraint you wrote, but would be checked dynamically instead of statically. That wouldn't fix the underlying issue (which is really that the algorithm to construct RDIR probably needs to fundamentally change) but it would fix most instances where we see symptoms like this.
SCR is gone, this is no longer relevant.
I've not managed to work out a way to do this without metaprogramming, but I have a file that causes this to fail at line 244 (
assert(flow.is_valid_node(from_node) and flow.is_valid_node(to_node))
). Full stack error trace:I've attached a small regent program that causes the error. The error goes away if you require
parts1 * parts2
, however the strategy for calling this does not allow for this requirement. Attaching the file will help, 1 sec doh.rdir_bug.txt