Hello Richard & Alan,

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

> On Mar 28, 2016, at 19:41 , Richard Henderson <r...@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

Reply via email to