This is the mail archive of the gcc@gcc.gnu.org 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 Wed, Apr 18, 2012 at 5:25 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 18, 2012 at 8:53 AM, Bin.Cheng <amker.cheng@gmail.com> 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.

Thanks
-- 
Best Regards.


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