This is the mail archive of the
mailing list for the GCC project.
Re: avoid alignment of static variables affecting stack's
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "Jakub Jelinek" <jakub at redhat dot com>,"Jeff Law" <law at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>,<hjl dot tools at gmail dot com>
- Date: Fri, 24 Oct 2014 10:01:36 +0100
- Subject: Re: avoid alignment of static variables affecting stack's
- Authentication-results: sourceware.org; auth=none
- References: <5448BCA30200007800041508 at mail dot emea dot novell dot com> <20141023065015 dot GX10376 at tucnak dot redhat dot com> <5448C5CB0200007800041532 at mail dot emea dot novell dot com> <5449454A dot 9050502 at redhat dot com>
>>> On 23.10.14 at 20:13, <email@example.com> wrote:
> On 10/23/14 01:09, Jan Beulich wrote:
>>>>> On 23.10.14 at 08:50, <firstname.lastname@example.org> 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.