On Tue, Apr 26, 2022 at 09:58:35AM +0200, Richard Biener wrote:
> > The following testcase regressed on riscv due to the splitting of critical
> > edges in the sink pass, similarly to x86_64 compared to GCC 11 we now swap
> > the edges, whether true or false edge goes to an empty forwarded bb.
> > From GIMPLE POV, those 2 forms are equivalent, but as can be seen here, for
> > some ifcvt opts it matters one way or another.
>
> Do we have evidence that one or the other form is "better"? There's
> the possibility to change CFG cleanup to process the edges in a
> defined {true,false} or {false,true} order rather than edge number order.
> Likewise we could order fallthru before EH or abnormal edges here.
> It would be a bit intrusive (and come at a cost) since currently we
> just iterate over all BBs, seeing if they are forwarders while ordering
> would require a different iteration scheme. But doing all this might
> also make the CFG cleanup result more stable with respect to IL
> representation changes.
I have the feeling that sometimes one order and sometimes another order is
better, sometimes one order means we reuse a pseudo, sometimes the other,
and in some cases reusing a pseudo disables ifcvt optimization, in another
is the only case where it works.
I think it is best to make ifcvt work with any orders, but not sure it will
be always possible. E.g. sometimes the reused pseudo means we need to
allocate an extra temporary, and while say RA can generate the same code
from it, during ifcvt the sequence now might have higher cost.
Also, we have the case of cond_move_process_if_block which doesn't bother
checking any costs, so it can force cases where we otherwise carefully punt
because of costs. I'm afraid to touch that this late and not really sure
I'll have time for it during stage1 either.
Jakub
