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

[Daniel Berlin]

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.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 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.

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 :)


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".