> -----Original Message----- > From: Andrew Pinski [mailto:pins...@gmail.com] > Sent: Tuesday, September 27, 2011 5:31 AM > To: Jiangning Liu > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix stack red zone bug (PR38644) > > On Mon, Sep 26, 2011 at 3:26 AM, Jiangning Liu <jiangning....@arm.com> > wrote: > > This patch is fix PR38644, a 3-year-old bug. > > > > From the discussions in mail list and bugzilla, I think the middle > end fix > > is a common view. Although there are stills some gaps on how to fix > it in > > middle end, I think this patch at least moves the problem from back- > end to > > middle-end, which makes GCC infrastructure stronger than before. > Otherwise, > > any back-end needs to "find" and fix this problem by itself. > > I don't see why you think that is the common view that the fix should > be in the middle-end. I and a few others think the back-end should be > where the barrier emitted from. The middle-end should not have stack > accesses as being special in anyway when it comes down to scheduling. > What happens when a new scheduler comes around? Then this has to be > fixed again in that new scheduler rather than having the barrier doing > the correct thing for all schedulers. >
Hi Andrew, Thanks for your kindly response! Sorry, for this bug, I don’t see your valuable comments previously in either bug zilla and the [RFC] I sent out long time ago in gcc mail list. What I see is a bunch of people agreed this problem should be fixed in middle end. For example, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644#c48 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644#c49 My comments, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644#c35 I'd like to repeat my points here. As I mentioned, it shouldn't be back-end's responsibility to "find" this problem, i.e. the instructions move over stack pointer change. ISAs can be split into two classes. One class doesn't support stack red zone, and the other class does support stack red zone. If we agree this is a general issue, I think this issue should be solved in middle end rather than in back-end. Yes. Back-end can provide barrier to explicitly represent the dependence, but I think this is a kind of workaround, because this way we are hoping back-end to detect this kind of dependence, while this kind of dependence is common for every back-end which doesn't support stack red zone. If we carefully analyze the implementation in x86 and powerpc back-ends supporting stack red zone, we may find, they are doing almost the same things. In particular, I think the retarget-ability is the most valuable treasure for GCC. Thinking of implementing a new port, do we want to write new code to "find" this problem, no matter whether the new port supports stack red zone or not? If the answer is YES, it means we need to write the similar code like what currently x86-64 and powerpc back-ends are doing. Obviously, it is a non-trivial work. This way I don't think it's good for GCC's retarget-ability. Why don't we abstract the common thing in middle-end with a very clean interface? Finally, It's OK for me if you say scheduler can only tread dependence as a "clean" interface. But this point doesn't support stack red zone issue must be handled in different back-ends respectively. If we want to keep scheduler clean enough, a simpler solution is adding a pass in middle-end to generate barrier before scheduler and this pass handle the general stack-red-zone issue using the interface I'm defining in the patch, but obviously this is a kind of over-design so far. Thanks, -Jiangning > Thanks, > Andrew Pinski
