Re: Minor issue with recent code to twiddle costs of pseudos with invariant equivalents

[Jeff Law <law at redhat dot com>]

On 06/10/10 14:44, Bernd Schmidt wrote:
> On 06/10/2010 10:37 PM, Jeff Law wrote:
>    
> > Compile the attached with -O2 on x86-unknown-linux-gnu and review the
> > .ira dump for main()
> >
> > starting the processing of deferred insns
> > ending the processing of deferred insns
> > df_analyze called
> > Building IRA IR
> > starting the processing of deferred insns
> > ending the processing of deferred insns
> > df_analyze called
> > init_insns for 59: (insn_list:REG_DEP_TRUE 5 (nil))
> > Reg 59 has equivalence, initial gains 4000
> >      
> [...]
>
>    
> >      r59: preferred NO_REGS, alternative NO_REGS, cover NO_REGS
> >      
> [...]
>    
> > Disposition:
> >      0:r59  l0   mem
> >      
>    
> > Ultimately I think reload is cleaning this up, but it seems awful
> > strange to have a pseudo/allocno which clearly should be allocated to a
> > hard GPR preferring NO_REGS and from an allocation standpoint living in
> > memory.
> >      
>  From the above, I don't see the problem.  Reg 59 is detected as
> reg_equiv_invariant, which means if we don't allocate a hard reg to it,
> we can substitute the invariant everywhere and save the initializing
> instruction.  As far as I can tell this is working exactly as intended.
>    
But shouldn't having an invariant form just decrease the priority for 
pseudo 59 to get a hard register?  The NO_REGS preferencing will totally 
disable register allocation for pseudo 59.

Just because we have an invariant equivalent form doesn't mean we should 
totally disable allocation -- if a hard reg is available, we're 
sometimes going to be better off using a hard reg to hold the value 
rather than substituting the equivalent form at each use of the pseudo.

Jeff
> Bernd
>
>