Re: avoid alignment of static variables affecting stack's

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 24.10.14 at 11:52, <richard.guenther@gmail.com> wrote:
> On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> 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
>> think.
> 
> I stand corrected then.

So am I to conclude then that I need to take out the hard register
check in order for this to be accepted?

Jan