On Wed, Sep 28, 2011 at 3:49 AM, Jiangning Liu <jiangning....@arm.com> wrote: > > >> -----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?
There are gazillion things you have to explicitly get right in your backends, so I don't see why exposing proper scheduling barriers should be special, and there, why red-zones should be special (as opposed to other occasions where you need to emit barriers from the backend for the scheduler). Richard. > 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 >> > >> > >> > >> > >> > >> > >> > >> > > > > > >
