This is the mail archive of the 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]

Re: avoid alignment of static variables affecting stack's

On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
> >> For something in static storage, this seems OK.  However, I think a hard
> >> register variable ought to be left alone -- even if we can't spill it to
> >> a stack slot today, there's a reasonable chance we might add that
> >> capability in the future.
> >
> > Hmm, but then wouldn't it need to be the code generating the spill
> > that's responsible for enforcing suitable alignment? I can certainly
> > re-submit without the hard register special cased (as it would still
> > fix the original issue I'm seeing), but it feels wrong to do so.
> Yes, ISTR the spilling code is supposed to update the required
> stack alignment.  After all the RA decision might affect required
> alignment of spills.

>From what I remember, at RA time you already have to know conservatively
that you'll want to do dynamic stack realignment and what the highest needed
alignment will be, so various parts of expansion etc. conservatively compute
what will be needed.  I think that is because you e.g. need to reserve some
registers (vDRAP, etc.) if doing dynamic realignment.
If you conservatively assume you'll need dynamic stack realignment and after
RA you find you really don't need it, there are some optimizations in
prologue threading where it attempts to at least decrease amount of
unnecessary code, but the harm has already been done.

Might be that with LRA perhaps this could be changed and not conservatively
assume more alignment than proven to be needed, but such code isn't there I


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