2016-02-02 16:14 GMT+03:00 H.J. Lu <hjl.to...@gmail.com>: > 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 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We call it after RA when all spill slots are allocated and check if we may relax stack alignment. Don't see any problem here. Thanks, Ilya > > 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.
