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
