>>> On 23.10.14 at 20:13, <l...@redhat.com> wrote: > On 10/23/14 01:09, Jan Beulich wrote: >>>>> On 23.10.14 at 08:50, <ja...@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
