> -----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. Thanks, -Jiangning > Richard.
