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, 2) huh, I doubt that this is the biggest issue one faces when implementing a new target, 3) I'm sure there are very many latent backend bugs not related to 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. > 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 >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> > >> > >> > >> > >> > > > > > >
