On Sun, Sep 4, 2011 at 6:44 AM, Tom de Vries <vr...@codesourcery.com> wrote: > On 09/04/2011 11:10 AM, Richard Guenther wrote: >> On Sun, Sep 4, 2011 at 11:00 AM, Tom de Vries <vr...@codesourcery.com> wrote: >>> Hi, >>> >>> this patch fixes PR50251, which was caused by r178353. >>> >>> The patch was bootstrapped and reg-tested on i686 and x86_64. >>> On i686, the test-cases reported failing in PR50251 pass again. >>> >>> The patch selects the DRAP type stack realignment method in case a >>> stack_restore >>> is used. If that is not done, the presence of the stack_restore at reload >>> leaves >>> FRAME_POINTER without an elimination rule for i386 port. >>> >>> OK for trunk? >> >> Shouldn't we eventually simply set cfun->calls_alloca when expanding either >> stack save or restore? Similar to how it is set from >> allocate_dynamic_stack_space? >> I'm not sure we encountered the dead stack save/restore pair before >> this new folding, >> so, just to make other targets not confused about them as well? > > Setting cfun->calls_alloca will work as well, but doesn't seem necessary to > me. > AFAIU, since other targets don't define MAX_STACK_ALIGNMENT, they don't need > to > do a realign themselves. If I disable MAX_STACK_ALIGNMENT on i386, the > middle-end handles the realign and the stack_restore causes no problems. So to > me this seems a problem with the i386-specific implementation of realignment. > > I'm more worried about other similar cases not working for i386 than about > other > ports. Another, more involved way to fix this, would be in reload to: > - calculate which registers we cannot use for elimination (which we already > do) > - pass that as context to target.can_eliminate. The i386 target can then > fulfill its requirement to be able to eliminate the frame pointer by > setting need_drap if the stack pointer is not available. > I think this way we could remove most if not all of the > 'crtl->need_drap = true' snippets, and have a completer solution and perhaps > also more optimal. >
There are 2 aspects in stack realignments: 1. Support stack variables with any alignment. 2. Support register spill with alignment > incoming stack alignment. You can test #2 on Sandy Bridge Linux by configuring gcc with --with-arch=corei7-avx. H.J.
