This is the mail archive of the gcc-patches@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: Patch ping ^ 2


Hello,

> >And why do you assume that the direction in that the patch takes it is
> >wrong?  It is the way at least one other compiler (LLVM) uses.
> 
> Not quite. At least, I don't believe it's quite the same.
> LLVM will hoist loads/sink stores if the addressing arithmetic for a 
> given load/store doesn't change.
> It doesn't look like you do that anymore, but i can't quite tell.
> IE they use the equivalent of single_reachable_address, called 
> PointerInvalidatedByLoop for loads, and an is_loop_invariant check for 
> stores, both of which it looks like you've removed (by removing 
> single_reachable_address).

PointerInvalidatedByLoop is equivalent to what the rewritten lim does using
count_tag_references and the check at the start of determine_lsm_ref,
given the limited amount of aliasing information we have now.

Moving of loads for that there are no aliasing stores is not part of
store motion and it is performed in
determine_invariantness/move_computations (using the virtual ssa).

> > It is
> >clean and very easy to understand and extend.  Also once the
> >msg01437.html is accepted (which it should, at least for 4.1, although 
> >I
> >think it is a bit too intrusive for 4.0), it is trivial to make it take
> >advantage of SSA form for virtual operands.
> >
> 
> I don't see how it would look much different from what we have now if 
> you did.
> I'd appreciate it if you could show me what you have in mind.

basically replacing the count_tag_references/determine_lsm_ref cycle by
traversing the UD chains in virtual operands from loads and stores in
the loop body.

Indeed it is fairly similar to what we do now, but it would not need to
scan also through DU chains as we do now (which seems to be one of the
reasons for compile time problems, since many of the uses we look at are
outside of the loop and therefore they are not interesting). It also would
not mix the steps of finding the memory references and determining their aliasing
relationships in a single relatively hard to understand function
(single_reachable_address).

Zdenek


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