[PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

Jakub Jelinek jakub@redhat.com
Tue Feb 2 12:29:00 GMT 2016


On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bizjak wrote:
> On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> >> The bottom line is  ix86_minimum_alignment must return the correct
> >> number for DImode or you can just turn off STV.   My suggestion is
> >> to use my patch.
> >
> > Uros, any preferences here?  I mean, it is possible to use
> > e.g. the ix86_option_override_internal and have H.J's ix86_minimum_alignment
> > change as a safety net, in the usual case for -mpreferred-stack-boundary=2
> > we'll just disable TARGET_STV and ix86_minimum_alignment change won't do
> > anything, as TARGET_STV will be false, and if for whatever case it gets
> > through (target attribute, -mincoming-stack-boundary=, ...)
> > ix86_minimum_alignment will be there to ensure enough stack alignment.
> > Most of the smaller -mpreferred-stack-boundary= uses are -mno-sse anyway,
> > and that is something we don't want to affect.
> 
> IMO, we should disable STV when -mpreferred-stack-boundary < 3, as STV
> is only an optimization. Perhaps we can also emit a "sorry" for
> explicit -mstv in case stack boundary requirement is not satisfied.
> *If* there is a need for -mstv with smaller stack boundary, we can
> revisit this decision for later gcc versions.
> 
> I think disabling STV is less surprising option than increasing stack
> boundary behind the user's back.

So, is http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02129.html
ok for trunk then (alone or with additional sorry, incremental or not?)?
I believe it does just that.

	Jakub



More information about the Gcc-patches mailing list