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. After all the targets emit the prologue/epilogue code, not the middle-end. 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"?) I don't know the scheduler or prologue/epilogue code very well (nor the problem at hand). Richard. > Thanks, > -Jiangning > > > >> Richard. > > > > >
