-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RyuJIT: Invalid ordering when assigning ref-return #10813
Comments
I have just now noticed/learned about the EDIT: That flag is set in |
I suppose @CarolEidt might know. Maybe "the use must occur before the def" due to overlapping concerns? Structs are unfortunately rather complicated to deal with. |
I was a bit stumped by this. The block ops ( I found the change that introduced this comment (a subsequent change moved it, and the associated setting of
I believe this is no longer relevant, because we no longer represent block ops this way, and although we still have this messiness to deal with in There's probably now other code that relies on this in some way, but I'm going to remove this setting of |
The first round of changes (just respecting the correct evaluation order), results in a small number of diffs - more negative than positive, but still a relatively small number of methods. I've as yet done only diff testing on x64, but am going to pursue a second round of changes. When I did the first set of "first class structs" changes (changing the block ops from I'm now working on eliminating the weird special handling of size, which I expect to also have a minimal impact, but in any event should have a PR up in the next day or two. |
cc @dotnet/jit-contrib - in case anyone has thoughts on this (see the comments above). |
This order was changed five years ago, as a workaround for data flow analysis issues around the block copy. Now that block copies are handled as regular assignments, this is no longer needed - and is, in fact, incorrect as it causes side effects to be handled in the wrong order. Fix #19243
This order was changed five years ago, as a workaround for data flow analysis issues around the block copy. Now that block copies are handled as regular assignments, this is no longer needed - and is, in fact, incorrect as it causes side effects to be handled in the wrong order. In the process, also remove the special-casing for the size operand of `DYN_BLK` under `ASG`. Fix #19243
This order was changed five years ago, as a workaround for data flow analysis issues around the block copy. Now that block copies are handled as regular assignments, this is no longer needed - and is, in fact, incorrect as it causes side effects to be handled in the wrong order. However, for the case where the lhs is an indirection of a local address, it must be evaluated 2nd for SSA renaming to be correct. In the process, also remove the special-casing for the size operand of `DYN_BLK` under `ASG`. Fix #19243
This order was changed five years ago, as a workaround for data flow analysis issues around the block copy. Now that block copies are handled as regular assignments, this is no longer needed - and is, in fact, incorrect as it causes side effects to be handled in the wrong order. However, for the case where the lhs is an indirection of a local address, it must be evaluated 2nd for SSA renaming to be correct. In the process, also remove the special-casing for the size operand of `DYN_BLK` under `ASG`. Fix #19243
The following example gives different results in debug and release:
The disassembly shows that the
s_13
reference is loaded before the call toM7
:As far as I can tell, everything looks fine before rationalize:
But rationalize seems to end up with this in the wrong order:
The text was updated successfully, but these errors were encountered: