> -----Original Message----- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: Tuesday, September 27, 2011 3:41 PM > To: Jiangning Liu > Cc: Andrew Pinski; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix stack red zone bug (PR38644) > > 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, Thanks for your explanation. It's explicit to back-end, while it's implicit to scheduler in middle end, because barrier can decide dependence in scheduler but barrier can be generated from several different scenarios. It's unsafe and prone to introduce bug if any one of the scenarios requiring generating barriers is being missed in back-end. Between middle-end and back-end, we should have interfaces that is easy to be implemented by back-end. After all, middle-end itself can't consist of a compiler, and vice versa. Back-end needs middle-end's help to make sure back-end is easy to be implemented and reduce the possibility of introducing bugs. Without an explicit hook as I'm proposing, back-end implementers have to clearly know all scenarios of generating barrier very clearly, because there isn't any code tips and comments in middle end telling back-end the list of all scenarios on generating barriers. Yes, barrier is a perfect interface for scheduler in theory. But from engineering point of view, I think it's better to explicitly define an interface to describe stack red zone and inform back-end, or vice versa. Not like computer, people is easy to make mistake if you don't tell them. On this bug, the fact is over the years different back-ends made similar bugs. GCC is really a perfect platform on building new ports, and I saw a lot of new back-ends. The current middle end is unsafe, if port doesn't support stack red zone and back-ends doesn't generate barrier for it. Why can't we explicitly clarify this in compiler code between middle end and back end? What if any other back-end (new or old) NOT supporting stack red zone exposing the similar bug again? Thanks, -Jiangning > 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 > > > > > > > > > > > > > > > >
