[LLVMdev] where should volatileness really live in the AA API?

[Philip Reames]

On 03/31/2015 03:41 PM, Daniel Berlin wrote:
> So, i'm working through the last of miniscule gvn optimizations, and
> one of the things that gets tested is whether it will eliminate
> non-volatile loads in favor of ohter non-volatile loads when there are
> volatile loads in the way.
I'm pretty sure I'm the one who added that set of test cases.  :)
> I.E.
> define i32 @test1(i32* nocapture %p, i32* nocapture %q) {
> entry:
>    %x = load i32, i32* %p
>    %0 = load volatile i32, i32* %q
>    %y = load i32, i32* %p
>    %add = sub i32 %y, %x
>    ret i32 %add
> }
>
>
> Currently, getModRefInfo will return Mod for getModRefInfo(%0,
> AA->getLocation(%y))
>
> This is because it punts on saying anything about ordered loads
I think this is a conservatively correct, but non ideal answer.  A 
correct answer would also be to return Ref or NoModRef (depending on 
actual aliasing of the underlying locations).  Ordering is not an 
alasing property and should not be reported as such.  However, I believe 
a large number of callers may expect this and fleshing out all those 
bugs may not be fun.

Also worth commenting on is that *volatile* and *ordering* have 
distinctly different properties.  We couple them in a lot of odd ways, 
but the reasoning and legal optimizations are quite different.

> I can certainly watch for this case in the caller, and ignore it if
> it's volatile load vs non-volatile load. This is what MemDep does.
Can you point to the code you're talking about?  A volatile load 
encountered during the normal instruction walk is treated like any other 
(provided we know the query instruction is non-volatile.)  We are 
conservative about volatile stores, but that's on my list to fix.

Note that we are really conservative about volatile query instructions.  
We also haven't done anything for the callsite dependency path.  (I've 
never really understood why that needed to be a separate codepath, but 
that's a different issue.)
>
> class Location is theoretically about pointers and sizes, but right
> now, our struct Location in AA already has metadata tags and other
> *instruction* specific info that it grabs from the instruction you
> pass to getLocation. IE it includes noalias data that it tries to
> match against other instructions.
> So we already have broken this abstraction to return better answers :)
I disagree with your interpretation here.  The aliasing metadata does 
describe the location as seen by the instruction it's derived from.  
However, the alias metadata means that locations which would otherwise 
alias, no longer do.  In effect, we have many distinct locations which 
might happen to map to the same address.
> Is there a good reason it shouldn't also grab the
> volatileness/orderedness from the original instruction, store it and
> use it to try to give better getModRefInfo answers too?
>
> Nothing that involves walking, sure, but it can trivially give the
> same answer to this case, which is "the volatile load does not affect
> the regular load".
I strongly believe that ordering and aliasing are distinct properties.

I think in practice we have two different bits of functionality mixed 
together.  Actual alias analysis should be done strictly in terms of 
Locations.  The question on whether two locations might alias is 
independent of what semantics might be associated with a given pair of 
accesses that are mayalias.

I would have no problem with having the wrapper APIs - which ask 
questions about the interactions between instructions - using 
information about volatile and ordering.  I'm really really queasy with 
the idea of a "volatile location" vs a non-volatile location. There 
might be a workable semantic model here, but it seems much harder to 
reason about.


> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev