> -----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. > 2) huh, I doubt that this is the > biggest issue > one faces when implementing a new target, I never say it is a *biggest* issue. It is only one of an issue. But for such a simple issue, we had a bunch of bug reports already over the years. So many people took so much time on this. Sometimes a very simple bug may be very annoying from engineering point of view. Right? > 3) I'm sure there are very > many > latent backend bugs not related to red-zone > Of course I'm talking about the bugs related to stack red zone. I mean for other back-ends other than x86/powerpc/ARM, there might still exit bug around stack red zone. > The middle-end isn't "safe by default" either if you have bogus > instruction patterns in your .md file, or you generate bogus IL > from the va-arg gimplification hook. A target bug is a target bug, > the middle-end can't and should not do anything to try to workaround > bugs in targets. > Well, for GCC I think the concept of middle end is pretty much like the concept of "shared code". Even some passes can work on both GIMPLE and RTL. I mean this specific stack red zone issue can be abstracted in shared for all ports, so it is quite related to middle end. I didn't say it has nothing to do with back-end. I'm arguing middle-end can help the simplified implementation of back-end around this. As I mentioned middle-end wouldn't live itself without specific target support on back-end, right? > > 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 > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > >
