This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix stack red zone bug (PR38644)
On Wed, Sep 28, 2011 at 11:10 AM, Jiangning Liu <jiangning.liu@arm.com> wrote:
>
>
>> -----Original Message-----
>> From: Richard Guenther [mailto:richard.guenther@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.liu@arm.com>
>> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Richard Guenther [mailto:richard.guenther@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.liu@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
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >
>> >
>> >
>
>
>
>
>