Re: rs6000 stack_tie mishap again

[Olivier Hainque <hainque at adacore dot com>]

Hello Richard & Alan,

Thanks for your feedback. Back on it after a few extra
experiments.

> On Mar 28, 2016, at 19:41 , Richard Henderson <rth@redhat.com> wrote:
> 
>> Let's see what rth thinks.  He did say the patch might need to be
>> redone.  :)
>> https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00072.html
> 
> I be surprised if this is works as expected without side-effects.  You've now exposed the restore of the frame pointer to alias analysis, and it's probably not seen as constant anymore.  As you reference, I expect that any patch that opens the epilogue to such scrutiny is going to have to special-case the frame pointer as well.

> That said, as Segher points out later in the thread, one can arrange for hard regs within the body to bleed into temporaries used within the epilogue, which is bad.  So perhaps this is exactly what's needed longer-term.  More investigation is required.

I'd be happy to help, as much as I can.

Can you please expand a bit on the kind of side-effects you'd expect
and hint at useful directions you believe the investigation should
take ? I have some ideas and would like to make sure they're in
line with what you think would be most relevant :)

> But I expect for stage4, the best solution is to strengthen the stack_tie pattern to block all memory.  Early scheduling of the stack frame deallocation (a simple logic insn) can't really be that important to performance.

My feeling as well. At least, it can't be important enough to warrant
a sustained exposure to the kind of bug we're discussing here.

Olivier