On Tue, Feb 2, 2016 at 5:11 AM, Ilya Enkovich <enkovich....@gmail.com> wrote:
> 2016-02-02 16:06 GMT+03:00 H.J. Lu <hjl.to...@gmail.com>:
>> On Tue, Feb 2, 2016 at 5:03 AM, Ilya Enkovich <enkovich....@gmail.com> wrote:
>>> 2016-02-02 15:46 GMT+03:00 H.J. Lu <hjl.to...@gmail.com>:
>>>> On Tue, Feb 2, 2016 at 4:30 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>> On Tue, Feb 2, 2016 at 4:29 AM, Jakub Jelinek <ja...@redhat.com> wrote:
>>>>>> On Tue, Feb 02, 2016 at 01:24:26PM +0100, Uros Bizjak 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.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> This patch is WRONG.
>>>>>
>>>>> --
>>>>> H.J.
>>>>
>>>> You will run into the same ICE with
>>>>
>>>> -mincoming-stack-boundary=2 -msse2 -O2 -m32
>>>>
>>>> in a leaf function which needs DImode spill/fill.
>>>
>>> Why would we need DImode spill/fill having no DImode registers?
>>>
>>
>> Because STV is enabled with
>>
>> -mincoming-stack-boundary=2 -msse2 -O2 -m32
>
> I misread it as -mpreferred-... So why would we fail having a proper
> preferred stack alignment? AFAIK leaf function doesn't affect
> alignment until we finalize it after RA.
>
/* Finalize stack_realign_needed flag, which will guide prologue/epilogue
to be generated in correct form. */
static void
ix86_finalize_stack_realign_flags (void)
{
/* Check if stack realign is really needed after reload, and
stores result in cfun */
unsigned int incoming_stack_boundary
= (crtl->parm_stack_boundary > ix86_incoming_stack_boundary
? crtl->parm_stack_boundary : ix86_incoming_stack_boundary);
unsigned int stack_realign
= (incoming_stack_boundary
< (crtl->is_leaf && !ix86_current_function_calls_tls_descriptor
? crtl->max_used_stack_slot_alignment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For leaf function, we check max_used_stack_slot_alignment.
Since ix86_minimum_alignment returns 32 for DImode.
We won't realign stack for DImode spill/fill.
: crtl->stack_alignment_needed));
--
H.J.
