On Fri, Oct 24, 2014 at 12:12 PM, Jan Beulich <jbeul...@suse.com> wrote: >>>> On 24.10.14 at 11:52, <richard.guent...@gmail.com> wrote: >> On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek <ja...@redhat.com> wrote: >>> On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote: >>>> >> For something in static storage, this seems OK. However, I think a hard >>>> >> register variable ought to be left alone -- even if we can't spill it to >>>> >> a stack slot today, there's a reasonable chance we might add that >>>> >> capability in the future. >>>> > >>>> > Hmm, but then wouldn't it need to be the code generating the spill >>>> > that's responsible for enforcing suitable alignment? I can certainly >>>> > re-submit without the hard register special cased (as it would still >>>> > fix the original issue I'm seeing), but it feels wrong to do so. >>>> >>>> Yes, ISTR the spilling code is supposed to update the required >>>> stack alignment. After all the RA decision might affect required >>>> alignment of spills. >>> >>> From what I remember, at RA time you already have to know conservatively >>> that you'll want to do dynamic stack realignment and what the highest needed >>> alignment will be, so various parts of expansion etc. conservatively compute >>> what will be needed. I think that is because you e.g. need to reserve some >>> registers (vDRAP, etc.) if doing dynamic realignment. >>> If you conservatively assume you'll need dynamic stack realignment and after >>> RA you find you really don't need it, there are some optimizations in >>> prologue threading where it attempts to at least decrease amount of >>> unnecessary code, but the harm has already been done. >>> >>> Might be that with LRA perhaps this could be changed and not conservatively >>> assume more alignment than proven to be needed, but such code isn't there I >>> think. >> >> I stand corrected then. > > So am I to conclude then that I need to take out the hard register > check in order for this to be accepted?
Yes. Thanks, Richard. > Jan >
