[llvm-dev] Status of llvm.invariant.{start|end}

[Anna Thomas via llvm-dev]

I think what we need is AA along with dominance information. Regarding an analysis pass that can be 
used in various transformation passes, perhaps MemorySSA can help with this sort of information? 
CC’ed folks who may be able to help here.

In the example you have, when checking for clobbering between call g and the load of a, 
we know that call g does not clobber the load if the invariant.start (which uses a) dominates call g,
and the invariant.start has no uses. If invariant.start has uses, we’ll need to check the dominance information of the use 
w.r.t. the call g as well. However, this sort of analysis does not scale well.

AFAIK, the only transformation where we actually use the knowledge of invariant.start is within LICM for hoisting loads.



Anna

 
> On Oct 31, 2017, at 6:22 PM, Yichao Yu <yyc1992 at gmail.com> wrote:
> 
>> Just to clarify: If g can modify %a in some way, the front end needs to
>> identify it and avoid adding
>> invariant.start.
> 
> OK cool, that's what I thought too.
> 
>> 
>> Once the invariant.start has been added by the front end,this is a perfectly
>> legal transform to do
>> based on the LLVM spec.
>> 
>> In fact we should be implementing this in LLVM, patches welcome :)
> 
> Which is kind of what I was asking about in the original post. The
> issue suggests that something needs rework and I'm not sure what
> exactly it is referring to.....
> 
> I am pretty interested in this optimization so I would have submitted
> a patch if I know how... I'm not really sure where this should be
> implemented so that all optimization passes can make use of it (AA?)
> and how the information should be translated (I wasn't able to find
> anything similar to this in AA)