On Nov 8, 2011, at 2:40 PM, Alan Modra wrote: > On Tue, Nov 08, 2011 at 11:37:57AM +0100, Olivier Hainque wrote: >> Joseph resorted to mem:scratch to impose a strong barrier. That's certainly >> safe and I don't think the performance impact can be significant, so this >> looks like a good way out. > > I agree. Our fancy powerpc stack deallocation barriers rely too much > on alias analysis, which as you've shown (thanks!) isn't reliable in > this instance. Other targets just use the mem:scratch barrier.
Right. While the instance we have at hand here involves a bug I think (r11 perceived as a base reg to symbol), I don't see that we have strong guarantees that the current assumptions hold for sure in absence of such a bug. >> I tried an approach in between here: replace the stack_tie insn by a >> frame_tie insn with frame_base_rtx as the second base. In the case above, >> with frame_base_rtx==r11, this is something like >> >> (set (mem/c:BLK (reg:SI 11 11) [0 A8]) >> (unspec:BLK [ >> (mem/c:BLK (reg:SI 11 11) [0 A8]) >> (mem/c:BLK (reg/f:SI 1 1) [0 A8]) > > Looks similar to > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282#c15 Exactly. The idea here is to use the same mechanism in the other places where emit_epilogue emits a tie, making sure that the tie mem access will conflict with the frame accesses by issuing a write from the same base register. Now, if we can indeed have frame accesses using different base registers and a tie is needed after that (needs double checking), well, we'll need several of them. We could probably abstract this away and "just" keep track of a set of base registers used before a tie gets emitted. I'm not convinced that the potential gain is worth the extra complexity and potential risk of running into another subtle subcase, with hard to track sporadic runtime failures for starters. I don't have numbers though. That's a port maintainer call, I guess ? Olivier
