JIT: fix fgDfsReversePostorder#82950
Conversation
This method was not doing a proper depth first search, so the reverse postorder it created was flawed.
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsThis method was not doing a proper depth first search, so the reverse postorder it created was flawed.
|
|
@jakobbotsch PTAL See #82926 (comment) for context. No diffs, which is a bit surprising. |
jakobbotsch
left a comment
There was a problem hiding this comment.
LGTM.
Is this equivalent to the existing code if we did the visited check/update when we actually pop the stack instead of before pushing on the stack?
I originally wondered that too, think that it would be messed up by cycles. EG a self cycle would repeatedly push / pop / push / pop. A second bit vector might fix this -- say tracking when a block is first popped and not pushing after that. |
The old algorithm was recently introduced in 26b6d0e. Although it is simpler, it may produce incorrect post-orderings, which may become problematic in the future. Coincidentally it was exactly the same algorithm used in RyuJIT, and the bug is so subtle that they just recently discovered it :') - dotnet/runtime#82950 This also adds a few micro opts in SuccIterator for perf and mem overhead.
This method was not doing a proper depth first search, so the reverse postorder it created was flawed.