Re: IRA conflict graph & alternative selection

[Jeff Law <law at redhat dot com>]

Ian Lance Taylor wrote:
> Jeff Law <law@redhat.com> writes:
>
>   
> > Ian Lance Taylor wrote:
> >     
> > > I see no reason for those to stay in reload (especially since I think
> > > reload should disappear entirely).  It is reasonable to pick the total
> > > maximum size of the stack frame, and thus resolve all displacement
> > > constraints, before register allocation.  Carefully relaxing these
> > > constraints during reload can give you slightly better results for some
> > > instructions, but only in very very few cases, and only in functions
> > > which already have unusually large stack frames.  I don't consider that
> > > to be an important optimization.  Given that, we can determine the
> > > maximum offset for all virtual registers before register allocation,
> > > which suffices for selection of insn constraint alternatives, and then
> > > determine the actual offset, once, after register allocation.
> > >   
> > >       
> > I would agree that careful relaxation of displacements is no longer as
> > important as it once was, I don't think we can just  hand wave away
> > the displacement issues
> >
> >  1. The stack frames don't have to be that big to bump up against
> > these problems.
> >
> >  2. The code we generate if we have to reload the address because the
> > displacement was out of range can be horrific
> >
> >  3. There are targets where other registers used in the insn determine
> > the range of the displacement.  ie, in a load from memory, the
> > destination register used determines the valid range of displacements
> > (+-16 bytes vs +-8k on one target I'm aware of.
> >     
>
> In all of thse cases, the relaxation loop can only affect a handful of
> instructions: the cases where saving a few less registers moves the
> offset within range.  Those few instructions can only occur in a handful
> of functions: the ones where the stack frame is so large that this
> becomes an issue at all.
>   
I disagree, particularly because of point #3.    I don't see how you can 
hand wave it away, that is unless you plan on just making every 
load/store of a stack variable/spill be assumed to be out of the +-16 
byte range which will generate absolutely horrible code.

On that particular target is isn't uncommon to have situations where you 
think you're going to be able to use the +-8k instruction, but because 
of spilling you end up using a different register and suddenly you're 
stuck with only being able to use +-16 byte offsets.


> I'm not handwaving away displacement issues in general.  I'm handwaving
> away the need to do relaxation, such that we adjust if we find that need
> to save one more or one fewer register.  If we eliminate that relaxation
> requirement, we can determine all displacements before register
> allocation.
>   
I still don't see it as that simple. 
>   
> >  4. Register eliminations complicates matters as well.  Enough that I
> > don't think you can set maximum offsets until you've finalized
> > everything in the stack -- which implies that you're done spilling.
> >     
>
> We clearly can set maximum offsets, if we are willing to sacrifice an
> optimization.  I argue that that optimization is inconsequential for
> 99.9% of all code, and avoidable (through refactoring and good inline
> heuristics) for 100% of all code.
>   
Without knowing the size of the frame, how do you plan on doing this 
without making the assumption that nothing is going to fit in the 
shorter displacement variants?  How can you do this when the range of 
valid displacements can change because the register you used got spilled 
and you got a register from a different class (which in turn has a 
drastically smaller set of valid displacements).

jeff