Hi!
On Mon, Nov 25, 2019 at 09:16:52PM +0000, Richard Sandiford wrote:
> Segher Boessenkool <seg...@kernel.crashing.org> writes:
> > I am wondering the other way around :-) Is what you do for combine2
> > something that would be more generally applicable/useful? That's what
> > I'm trying to find out :-)
> >
> > What combine does could use some improvement, if you want to hear a
> > more direct motivations. LOG_LINKS just skip references we cannot
> > handle (and some more), so we always have to do modified_between etc.,
> > which hurts.
>
> The trade-offs behind the choice of representation are very specific
> to the pass.
Yes, but hopefully not so specific that every pass needs a completely
different representation ;-)
> >> >> Target Tests Delta Best Worst Median
> >> >> avr-elf 1341 -111401 -13824 680 -10
> >> >
> >> > Things like this are kind of suspicious :-)
> >>
> >> Yeah. This mostly seems to come from mopping up the extra moves created
> >> by make_more_copies. So we have combinations like:
> >>
> >> 58: r70:SF=r94:SF
> >> REG_DEAD r94:SF
> >> 60: r22:SF=r70:SF
> >> REG_DEAD r70:SF
> >
> > Why didn't combine do this? A target problem?
>
> Seems to be because combine rejects hard-reg destinations whose classes
> are likely spilled (cant_combine_insn_p).
Ah, okay. And that is required to prevent ICEs, in combine2 as well
then -- ICEs in RA.
There should be a better way to do this.
> This SF argument register
> happens to overlap POINTER_X_REGS and POINTER_Y_REGS and so we reject
> the combination based on POINTER_X_REGS being likely spilled.
static bool
avr_class_likely_spilled_p (reg_class_t c)
{
return (c != ALL_REGS &&
(AVR_TINY ? 1 : c != ADDW_REGS));
}
So this target severely shackles combine. Does it have to? If so, why
not with combine2?
> >> So there's only one case in which it isn't a win, but the number of
> >> tests is tiny. So I agree there's no justification for trying this in
> >> combine proper as things stand (and I wasn't arguing otherwise FWIW).
> >> I'd still like to keep it in the new pass because it does help
> >> *sometimes* and there's no sign yet that it has a noticeable
> >> compile-time cost.
> >
> > So when does it help? I can only think of cases where there are
> > problems elsewhere.
>
> The full list of affected tests (all at -O2 -ftree-vectorize) are:
I'll have to look at this closer later, sorry.
Segher
