[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 2 Jun 2020, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
> 
> --- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
> (In reply to Kito Cheng from comment #6)
> > Created attachment 48658 [details]
> > i386-Implement-ROUND_TYPE_ALIGN-to-make-sure-alignme.patch
> > 
> > Some optimization might made decision depend on the alignment, and alignment
> > shrinking might made the decision become wrong.
> 
> Nothing will happen on i386 if alignment of long long isn't 8 bytes.

GIMPLE passes see DECL_ALIGN and can for example elide runtime checks
like if(_Alignof(var) != 8) which is bogus when the actual alignment
is not ensured.  For this reason we cannot permit a larger aligment
early and resort to a lower one later.

> > So I prefer keep the assertion checking and implement ROUND_TYPE_ALIGN for
> > x86, so that it will set the alignment properly from the beginning.
> > 
> > PoC/untested  patch attached.
> 
> The i386 psABI specifies 4 byte alignment for long long.  But we want to
> use 8 byte alignment if there is no ABI implication and no stack realignment
> is needed.  Will ROUND_TYPE_ALIGN always align long long to 8 bytes?

So what we want here is RTL expansion pad out stack slots if they know
to be aligned but not adjust DECL_ALIGN.  Not sure if there's already
a target hook to pad out variables, if not this may be the way to get
what you desire here.

I guess the actual reason is crossing of cache-lines?