Re: avoid alignment of static variables affecting stack's

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

>>> On 23.10.14 at 20:13, <law@redhat.com> wrote:
> On 10/23/14 01:09, Jan Beulich wrote:
>>>>> On 23.10.14 at 08:50, <jakub@redhat.com> wrote:
>>> On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
>>>> Function (or more narrow) scope static variables (as well as others not
>>>> placed on the stack) should also not have any effect on the stack
>>>> alignment. I noticed the issue first with Linux'es dynamic_pr_debug()
>>>> construct using an 8-byte aligned sub-file-scope local variable.
>>>>
>>>> According to my checking bad behavior started with 4.6.x (4.5.3 was
>>>> still okay), but generated code got quite a bit worse as of 4.9.0.
>>>
>>> If the static/external var has BLKmode, then perhaps it is safe, but I
>>> wonder about other vars, say vectors etc.  Such vars are most likely
>>> loaded from their memory location, and if for some reason that needs to be
>>> spilled again, stack realignment would not be able to do that.
>>> Or do we inspect the IL and for any pseudos with modes needing larger
>>> alignment we adjust the dynamic stack realignment fields?
>>
>> I don't know, but it would seem to me that this ought to happen
>> anyway: If the pseudo holds the result of some computation
>> other than a simple load from memory and needs spilling, the same
>> would apply afaict.
> 
> 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.

Jan