> -----Original Message----- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Thursday, September 29, 2011 6:14 PM > To: Jiangning Liu > Cc: 'Richard Guenther'; Andrew Pinski; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] Fix stack red zone bug (PR38644) > > On Thu, Sep 29, 2011 at 06:08:50PM +0800, Jiangning Liu wrote: > > 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. > > But you don't want to listen about any other alternative, other > backends are > happy with being able to put the best kind of barrier at the best spot > in the epilogue and don't need a "generic" solution which won't model > very > well the target diversity anyway.
Jakub, Appreciate for your attention on this issue, 1) Can you clarify who are the "others back-ends"? Does it cover most of the back-ends being supported by GCC right now? 2) You need give data to prove "other back-ends" are happy with current solution. The fact is over the years there are a bunch of bugs filed against this problem. WHY? At this point you are implying "other back-ends" are happy with bugs or potential bugs? This is wired to me. Also, this is not a issue whether a back-end is able to implement barrier or not. If you are really asking "able or not", I would say every back-end is able, but it doesn't mean "able" is correct and it doesn't mean "able" is the most reasonable. Comparing with the one I am proposing, I don't see the current solution has other significant advantages in addition to the "proper modeling" for scheduler you are arguing. Instead, the solution I'm proposing is a safe solution, and a solution easy to avoid bugs. If GCC compiler infrastructure can't even give a safe compilation, why should we insist on the "proper modeling" for scheduler only? Hopefully you can consider again about this. -Jiangning > > Jakub
