This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/64110] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110

--- Comment #15 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Vladimir Makarov from comment #13)
> > (In reply to Jakub Jelinek from comment #11)
> > > Looking at the generated assembly, I see there:
> > >         movw    %di, -80(%rbp)
> > >         vpbroadcastw    -80(%rbp), %ymm1
> > >         vmovdqa %ymm1, -80(%rbp)
> > > I'd have expected
> > >         vmovd   %edi, %xmm1
> > >         vpbroadcastw    %xmm1, %ymm1
> > >         vmovdqa %ymm1, -80(%rbp)
> > > Is there some bug in the *vec_dupv16hi pattern that LRA can't use the !r
> > > alternative?  %di should be valid nonimmediate_operand in HImode.  For e.g.
> > 
> > I know about the problem.  It is coming from a different treatment of ! in
> > LRA and reload.  I am going to work on this but as the fix would be in very
> > sensitive LRA part. I am afraid to fix it before my vacation.  So probably
> > it will be solved only in January.
> 
> Np, and thanks a lot.
> 
> The ! has been added by me for PR63594, so it isn't there from the era when
> i?86 backend was using reload.  If there is a better way to express that RA
> should prefer to use memory or xmm register and only use r constraint if it
> already is in a r register and doesn't need to be reloaded, I can use that. 
> Whether it is ?, ??? or something else.  ! description in gcc docs just
> fitted most what I wanted...

Jakub, I've checked this particular test and LRA works in the same way as
reload and as specified in the GCC documentation which mainly says that '!' is
ignored only when *all* operands satisfy the alternative constraints.  In this
case there is one reload therefore alternative with '!r' is rejected.  I
understand that for this insn the desirable behaviour is to reject alternative
only when operand with '!r' needs a reload.

I could implement such functionality.  The following unreserved special
characters can be used as such modifier with the new functionality:
   @ $ ^ -

What character would you prefer, Jakub?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]