On Tue, Sep 27, 2011 at 5:32 AM, Jiangning Liu <jiangning....@arm.com> wrote: >> Think of it this way. What the IR says is there is no barrier between >> those moves. You either have an implicit barrier (which is what you >> are proposing) or you have it explicitly. I think we all rather have >> more things explicit rather than implicit in the IR. And that has >> been the overall feeling for a few years now. >> > > Sorry, I'm afraid I can't agree with you. Instead, I think using barrier to > describe this kind of dependence is a kind of implicit method. Please note > that this is not an usual data dependence issue. The stack pointer change > doesn't have any dependence with memory access at all.
It is similar to atomic instructions that require being an optimization/memory barrier. Sure it is not a usual data dependence (otherwise we would handle it already), so the targets have to explicitly express the dependence somehow, for which we only have barriers right now. Richard. > No matter what solution itself is, the problem itself is a quite a common one > on ISA level, so we should solve it in middle-end, because middle-end is > shared for all ports. > > My proposal avoids problems in future. Any new ports and new back-end > implementations needn't explicitly define this hook in a very safe way. But > if one port wants to "unsafely" introduce red zone, we can explicitly define > this hook in back-end. This way, we would avoid the bug in the earliest time. > Do you really want to hide this problem in back-end silently? And wait others > to report bug and then waste time to get it fixed again? > > The facts I see is over the years, for different ports reported the similar > issue around this, and somebody tried to fix them. Actually, this kind of > problem should be fixed in design level. If the first people solve this bug > can give solution in middle end, we would not need to waste time on filing > those bugs in bug zilla and fixing them around this problem. > > Thanks, > -Jiangning > > > > > > > >
