Re: PATCH: PR target/53383: Allow -mpreferred-stack-boundary=3 on x86-64

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, May 30, 2012 at 11:13 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, May 25, 2012 at 6:53 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Sun, May 20, 2012 at 7:47 AM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>>> Hi,
>>>
>>> This patch allows -mpreferred-stack-boundary=3 on x86-64 when SSE is
>>> disabled. ?Since this option changes ABI, I also added a warning for
>>> -mpreferred-stack-boundary=3. ?OK for trunk?
>>>
>>> Thanks.
>>>
>>>
>>> H.J.
>>> ----
>>> ? ? ? ?PR target/53383
>>> ? ? ? ?* doc/invoke.texi: Add a warning for -mpreferred-stack-boundary=3.
>>>
>>> ? ? ? ?* config/i386/i386.c (ix86_option_override_internal): Allow
>>> ? ? ? ?-mpreferred-stack-boundary=3 for 64-bit if SSE is disenabled.
>>>
>>> ? ? ? ?* config/i386/i386.h (MIN_STACK_BOUNDARY): Set to 64 for 64-bit
>>> ? ? ? ?if SSE is disenabled.
>>>
>>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>>> index eca542c..338d387 100644
>>> --- a/gcc/config/i386/i386.c
>>> +++ b/gcc/config/i386/i386.c
>>> @@ -3660,7 +3660,7 @@ ix86_option_override_internal (bool main_args_p)
>>> ? ix86_preferred_stack_boundary = PREFERRED_STACK_BOUNDARY_DEFAULT;
>>> ? if (global_options_set.x_ix86_preferred_stack_boundary_arg)
>>> ? ? {
>>> - ? ? ?int min = (TARGET_64BIT ? 4 : 2);
>>> + ? ? ?int min = (TARGET_64BIT ? (TARGET_SSE ? 4 : 3) : 2);
>>> ? ? ? int max = (TARGET_SEH ? 4 : 12);
>>>
>>> ? ? ? if (ix86_preferred_stack_boundary_arg < min
>>> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
>>> index ddb3645..f7f13d2 100644
>>> --- a/gcc/config/i386/i386.h
>>> +++ b/gcc/config/i386/i386.h
>>> @@ -708,7 +708,7 @@ enum target_cpu_default
>>> ?#define MAIN_STACK_BOUNDARY (TARGET_64BIT ? 128 : 32)
>>>
>>> ?/* Minimum stack boundary. ?*/
>>> -#define MIN_STACK_BOUNDARY (TARGET_64BIT ? 128 : 32)
>>> +#define MIN_STACK_BOUNDARY (TARGET_64BIT ? (TARGET_SSE ? 128 : 64) : 32)
>>>
>>> ?/* Boundary (in *bits*) on which the stack pointer prefers to be
>>> ? ?aligned; the compiler cannot rely on having this alignment. ?*/
>>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>>> index 4c5c79f..daa1f3a 100644
>>> --- a/gcc/doc/invoke.texi
>>> +++ b/gcc/doc/invoke.texi
>>> @@ -13521,6 +13521,12 @@ Attempt to keep the stack boundary aligned to a 2 raised to @var{num}
>>> ?byte boundary. ?If @option{-mpreferred-stack-boundary} is not specified,
>>> ?the default is 4 (16 bytes or 128 bits).
>>>
>>> +@strong{Warning:} When generating code for the x86-64 architecture with
>>> +SSE extensions disabled, @option{-mpreferred-stack-boundary=3} can be
>>> +used to keep the stack boundary aligned to 8 byte boundary. ?You must
>>> +build all modules with @option{-mpreferred-stack-boundary=3}, including
>>> +any libraries. ?This includes the system libraries and startup modules.
>>> +
>>> ?@item -mincoming-stack-boundary=@var{num}
>>> ?@opindex mincoming-stack-boundary
>>> ?Assume the incoming stack is aligned to a 2 raised to @var{num} byte
>>
>> I applied the above patch to GCC 4.7 and the following patch to
>> Linux kernel 3.4.0. ?Kernel boots and runs correctly. ?Is the patch
>> OK for trunk?
>>
>> Thanks.
>>
>> --
>> H.J.
>> ---
>> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>> index 94e91e4..cd4a4f7 100644
>> --- a/arch/x86/Makefile
>> +++ b/arch/x86/Makefile
>> @@ -49,6 +49,9 @@ else
>> ? ? ? ? KBUILD_AFLAGS += -m64
>> ? ? ? ? KBUILD_CFLAGS += -m64
>>
>> + ? ? ? # Use -mpreferred-stack-boundary=3 if supported.
>> + ? ? ? KBUILD_CFLAGS += $(call cc-option,-mno-sse -mpreferred-stack-boundary=3)
>> +
>> ? ? ? ? # FIXME - should be integrated in Makefile.cpu (Makefile_32.cpu)
>> ? ? ? ? cflags-$(CONFIG_MK8) += $(call cc-option,-march=k8)
>> ? ? ? ? cflags-$(CONFIG_MPSC) += $(call cc-option,-march=nocona)
>
> Ping
>

Ping.

I have been running Linux kernel compiled with this option for
weeks.  Since -mpreferred-stack-boundary=3 will only be allowed
with -mno-sse, it will be used only with incompatible ABI.  Any
objections to this patch?

Thanks.


-- 
H.J.