> -----Original Message----- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: Wednesday, September 28, 2011 4:39 PM > To: Jiangning Liu > Cc: Andrew Pinski; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix stack red zone bug (PR38644) > > 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, This is because, 1) Current scheduler is unsafe if back-end doesn't generate barrier for a port which doesn't support stack red zone at all. 2) Implementing barrier in back-end is a burden to new back-end implementation for ports not supporting stack red zone at all. 3) There are many other ports not reporting bugs around this. I doubt there isn't bug for them. 4) There are over 300 TARGET HOOKS being defined in target.def. I don't think adding this interface is hurting GCC. BTW, really appreciate your close attention to this specific issue. Thanks, -Jiangning > 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 > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > >