On Tue, Feb 2, 2016 at 5:55 AM, Ilya Enkovich <enkovich....@gmail.com> wrote: > 2016-02-02 16:25 GMT+03:00 H.J. Lu <hjl.to...@gmail.com>: >> On Tue, Feb 2, 2016 at 5:21 AM, Ilya Enkovich <enkovich....@gmail.com> wrote: >>> 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. >> >> Please see >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454#c26 >> >> Why did LRA crash then? > > Because it tries a patch [1] which doesn't fix stack alignment and STV > enabling and therefore doesn't resolve the problem when > -mpreferred-stack-boundary=2 is used. >
No, it is because RA doesn't increase stack alignment. You have to have the correct stack alignment requirement before entering RA. -- H.J.
