Re: PATCH: PR target/40470: unabl e to find a register to spill in class ‘SSE_FIRST_REG’

[Vladimir Makarov <vmakarov at redhat dot com>]

H.J. Lu wrote:
> On Wed, Jun 17, 2009 at 8:22 AM, Jeff Law<law@redhat.com> wrote:
>   
> > Steven Bosscher wrote:
> >     
> > > On 6/17/09, Jeff Law <law@redhat.com> wrote:
> > >
> > >       
> > > > Richard Guenther wrote:
> > > >
> > > >         
> > > > > On Wed, Jun 17, 2009 at 4:01 PM, H.J. Lu<hongjiu.lu@intel.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >           
> > > > > > Hi,
> > > > > >
> > > > > > Some SSE4 instructions have implicit XMM0 operand. This patch helps RA
> > > > > > deal with them by forcing operand into XMM0 during expand. OK for trunk
> > > > > > and 4.4?
> > > > > >
> > > > > >
> > > > > >
> > > > > >             
> > > > > I don't think it's a particularly good idea to put things in hardregs
> > > > > that early.
> > > > >
> > > > >
> > > > >
> > > > >           
> > > > Agreed.  In fact, it can have horrific performance impacts.
> > > >
> > > >         
> > > Why? Most optimizazions that can be done for this insn can only be
> > > done on GIMPLE, right?  And the insn must have that specific register.
> > > So unless I am missing something, I don't see why this patch would do
> > > any harm.
> > >
> > >       
> > It'll completely disable the RTL loop optimizers.  Granted this is less
> > important today than before, but it's still bad.  And more importantly, the
> > register allocators and reload should be fixed to DTRT rather than hacking
> > around them.
> >     
>
>   
I am agree with Jeff and Richard.  There is one more reason to avoid 
using hard registers.  Usage of hard registers tends to create more 
spill failures in reload.
> I am all for it. Vladimir, how hard to fix RA for this?
>
>   
IRA does not generate spill code for insn constraints.  Reload does it.  
To fix it in reload (spill and restore hard registers) is not a trivial 
task and potentially distracting compiler stability for many targets.  
So I'd rather avoid it even if it could solve other passes problems like 
1st insn scheduling for x86/x86_64.

The originally problem occurs in the combiner (it propagates xmm0 usage 
right after a call through the insn in question).  So imho I think the 
best way is to fix in the combiner.