On Wed, Sep 28, 2011 at 11:40 AM, Jiangning Liu <jiangning....@arm.com> wrote: > > >> -----Original Message----- >> From: Richard Guenther [mailto:richard.guent...@gmail.com] >> Sent: Wednesday, September 28, 2011 5:20 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 11:10 AM, Jiangning Liu <jiangning....@arm.com> >> wrote: >> > >> > >> >> -----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. >> >> I don't argue that your solution is not acceptable, just your reasoning >> is bogus IMHO. >> 1) is a target bug, > > Why should back-ends handle a thing that doesn't exist at all for them? I > don't see clear logic here.
I don't think this is the case here. You need barriers to avoid scheduling certain instructions. That other targets don't need this because they have a red-zone doesn't mean you have to "handle a red-zone" - you clearly don't - you simply need to properly model dependences for the scheduler. Richard.
