This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About sink load from memory in tree-ssa-sink.c

On Fri, Apr 20, 2012 at 11:04 AM, Bin.Cheng <> wrote:
> On Fri, Apr 20, 2012 at 4:54 PM, Richard Guenther
> <> wrote:
>> On Fri, Apr 20, 2012 at 9:52 AM, Bin.Cheng <> wrote:
>>> On Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther
>>> <> wrote:
>>>> On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng <> wrote:
>>>> I don't understand method 2. ?I'd do
>>>> ?start at the single predecessor of the sink-to block
>>>> ?foreach stmt from the end to the beginning of that block
>>>> ? if the stmt has a VDEF or the same VUSE as the stmt we sink, break
>>>> ?(continue searching for VDEFs in predecessors - that now gets more expensive,
>>>> ?I suppose limiting sinking to the cases where the above finds sth
>>>> would be easiest,
>>>> ?even limiting sinking to never sink across any stores)
>>>> ?walk the vuse -> vdef chain, using refs_anti_dependent_p to see whether
>>>> ?the load is clobbered.
>>>> But I'd suggest limiting the sinking to never sink across stores - the alias
>>>> memory model we have in GCC seriously limits these anyway. ?How would
>>>> the numbers change if you do that?
>>> Interesting, maybe method 1 I implemented is too conservative.
>>> I implemented as you described, and the numbers are:
>>> 1) ? ?766, If the stop condition is "stmt_may_clobber_ref_p"
>>> 2) ? ?719, if the stop condition is "gimple_vdef || stmt_may_clobber_ref_p"
>>> Also, I past make check on x86 for 1).
>>> Is it good? I am not sure about it since bootstrapping builds gcc 2
>>> times and libraries 3 times.
>> For 2) it is enough to test for gimple_vdef. ?I think that's the most reasonable
>> approach - we can improve on it once we see that doing so would improve
>> things for a testcase.
> I am a little confused.
> does not "gimple_code (stmt) == GIMPLE_ASM"/"call_may_clobber_ref_p_1
> (stmt, ref)"
> matter? These are checked by stmt_may_clobber_ref_p.

All things that clobber anything have gimple_vdef () != NULL.  Thus in
gimple_vdef () != NULL || stmt_may_clobber_ref_p, stmt_may_clobber_ref_p
is never true if gimple_vdef () is NULL.

stmt_may_clobber_ref_p isn't checking for a NULL gimple_vdef, but that's
because you are not supposed to even have called it then.


> Thanks.
> --
> Best Regards.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]