On Tue, Feb 2, 2016 at 4:24 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Tue, Feb 2, 2016 at 12:53 PM, Jakub Jelinek <ja...@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. > > Uros.
My ix86_minimum_alignment change is for correctness, which is required for DImode spill/fill unless LRA supports unaligned spill/fill. Disabling TARGET_STV for -mpreferred-stack-boundary=2 is an optimization. Let me point it out again. Checking -mpreferred-stack-boundary < 3 to disable STV won't work for 32-bit incoming stack boundary and 64-bit preferred stack boundary. In this case, STV is on. When LRA needs 64-bit aligned stack slot, stack must be realigned. But for leaf function, we may not realign stack if ix86_minimum_alignment returns 32 for DImode. We must return 64 for DImode if STV is on in ix86_minimum_alignment. -- H.J.
