[LLVMdev] alias set collapse and LICM

[Hal Finkel]

----- Original Message -----
> From: "Sanjoy Das" <sanjoy at playingwithpointers.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Philip Reames" <listmail at philipreames.com>, "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing
> List" <llvmdev at cs.uiuc.edu>, "Daniel Berlin" <dberlin at dberlin.org>
> Sent: Monday, April 27, 2015 5:55:31 PM
> Subject: Re: alias set collapse and LICM
> 
> > Each alias set currently keeps track of its AccessType
> > (Ref/Mod/ModRef). Maybe we should not collapse Ref access sets
> > with Mod ones?
> 
> AFAICT, then the read only call will have to be in two alias sets --
> a
> Ref alias set (also containing %a) and a Mod alias set (also
> containing %b and %c).  The collapse is driven by the fact that a
> alias sets are disjoint -- to not collapse I think we'll have to
> break
> that invariant.

That's correct. There are only a few passes that use AST, however, and I don't think updating them would be too much trouble.

 -Hal

> 
> -- Sanjoy
> 
> >
> >  -Hal
> >
> >>
> >> One potential fix is to do N^2 alias queries (every mem operation
> >> in
> >> the loop with every other mem operation) before hoisting a load,
> >> but
> >> I
> >> suspect AliasSetTracker exists mainly to make LICM faster than
> >> N^2,
> >> so
> >> I'm ruling this solution out.
> >>
> >> The solution I like: have LICM create two AliasSetTracker
> >> objects.  The first one tracks all memory operations, as the alias
> >> set
> >> tracker object does now.  The second one only tracks mods.  When
> >> hoisting a load we check if any alias set in the mod tracker
> >> aliases
> >> the load location -- if not, the load is okay to hoist to the
> >> preheader from the data dependence point of view.  In the worst
> >> case,
> >> this is 2x more (than now) work for building the alias sets and no
> >> more
> >> extra work when checking if we can hoist a load.
> >>
> >> Before I dive into implementing this, I have a few questions:
> >>
> >>  * is this even the right problem to solve?  Or should I look at
> >>  other
> >>    passes for this optimization?
> >>
> >>  * do you think this will be too expensive?  If so, does it make
> >>  sense
> >>    to do this only on -O3?`
> >>
> >> -- Sanjoy
> >>
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory