> This fixes PR52803 - when we do not enter the pass_loop2 sub-pass
> queue nothing will execute pass_rtl_loop_done.  But we still need
> to destroy loops, which are preserved until after pass_loop2.
> Doing so in the gate of pass_loop2 is ugly, but destroyed
> properties are ignored if the gate returns false.  Another
> solution would be to destroy loops earlier dependent on
> gate_handle_loop2 - but that's equally ugly.  Another solution
> would be to add a pass after pass_loop2 that only destroys
> loops (also ugly).
> Honza, how is this part of the pass manager supposed to work?

Did not think of much of alternatives. We can have pass just after loop
destroying the loop structure or perhaps we can simply run loop init/uninit
always even if all the subpasses are disabled.  Would be a bit smoother, but
also wasteful.


Reply via email to