> -----Original Message----- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: Thursday, September 29, 2011 5:03 PM > To: Jiangning Liu > Cc: Andrew Pinski; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix stack red zone bug (PR38644) > > On Thu, Sep 29, 2011 at 5:13 AM, Jiangning Liu <jiangning....@arm.com> > wrote: > > > > > >> -----Original Message----- > >> From: Richard Guenther [mailto:richard.guent...@gmail.com] > >> Sent: Wednesday, September 28, 2011 5:56 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: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, > > > > My understanding here "model dependences" is explicitly adding > barrier in > > back-end for stack red zone purpose. And this is also how x86 and > power pc > > are doing in back-end. So it definitely means we have to "handle a > > red-zone". Otherwise, would not see so many codes in back-ends > explicitly > > marking with "red zone" comments. > > > > GCC has the following 41 ports right now, > > > > alpha > > arc > > arm > > avr > > bfin > > cris > > crx > > fr30 > > frv > > h8300 > > i386 > > ia64 > > iq2000 > > lm32 > > m32c > > m32r > > m68hc11 > > m68k > > mcore > > mep > > microblaze > > mips > > mmix > > mn10300 > > moxie > > pa > > pdp11 > > picochip > > rs6000 > > rx > > s390 > > score > > sh > > soft-fp > > sparc > > spu > > stormy16 > > v850 > > vax > > vms > > xtensa > > > > And I only see X86_MS_64 ABI and POWER_AIX ABI are supporting red > zone. > > > > ------------------------------------------------------------- > > | ARCH | ARM | X86 | POWER | others | > > |----------|-------|---------------|---------------|--------| > > | ABI | EABI | MS_64 | other | AIX | V4 | | > > |----------|-------|-------|-------|--------|------|--------| > > | RED ZONE | No | YES | No | YES | No | No | > > ------------------------------------------------------------- > > > > So are you really expecting all targets other than x86_MS_64 and > POWER_AIX > > have to explicitly write code in back-end to insert barrier just > because of > > not supporting stack red zone? This is ridiculous for me. > > > > For all other targets potentially they all may have bugs around this. > (Maybe > > somebody working for other targets can help to have a try on the > cases given > > in PR38644 and PR30282.) I have to say scheduler is unsafe at this > point. > > > > Hopefully you can consider this problem again. > > As far as I see only targets know where to best insert the barrier.
Yes. Agree. So this is why I say it would a burden for back-end if we use barrier to handle this case. > After > all the targets emit the prologue/epilogue code, not the middle-end. > I can see some prologue/epilogue hooks, but they are only for the top level hook-ups. > But well, I'm just arguing from the point that we want explicit > representations > of dependences (and other things) rather than implicit ones where then > middle-end code needs to remember to check some weird target macros > (same argument applies - why should somebody writing a middle-end > pass need to worry about target specialities with dependences - why > can't the targets "work ok by default"?) My answer is the world is not perfect, and we need to hide something for middle end. This is why so many TARGET HOOKs are being defined in target.def and used in middle end. This way middle end doesn't need to care what back-end implements the details at all. I think a lot of middle-end codes already checked "wired" target macros. I think what you are concerning is scheduler shouldn't check this "wired" target macros. IMHO, I also think scheduler should be pure enough and not ask it to be contaminated by this implicit barriers. But the problem here is we are trying to build a robust GCC infrastructure rather than only a robust scheduler. Without the diversity of so many back-ends, the world would be pure as you want. > > I don't know the scheduler or prologue/epilogue code very well (nor the > problem at hand). > As far as I know different back-ends are implementing different prologue/epilogue in GCC. If one day this part can be refined and abstracted as well, I would say solving this stack-red-zone problem in shared prologue/epilogue code would be a perfect solution, and barrier can be inserted there. I'm not saying you are wrong on keeping scheduler using a pure barrier interface. From engineering point of view, I only feel my proposal is so far so good, because this patch at least solve the problem for all targets in a quite simple way. Maybe it can be improved in future based on this. > Richard. > > > Thanks, > > -Jiangning > > > > > > > >> Richard. > > > > > > > > > >
