On Tue, 26 Apr 2022, Jakub Jelinek wrote:
> 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.
Agreed.
> 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.
OK, I'm keeping sanitizing CFG cleanup on my TODO for stage1 since I
want to look at the critical edge split / forwarder removal anyway for
other reasons.
Richard.
