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

[Daniel Berlin]

On Thu, Apr 16, 2015 at 7:12 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
>> To: llvmdev at cs.uiuc.edu
>> Sent: Wednesday, April 1, 2015 5:39:15 AM
>> Subject: Re: [LLVMdev] where should volatileness really live in the AA API?
>>
>> On 3/31/2015 5:41 PM, Daniel Berlin wrote:
>> >
>> > 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 it using anything other than alias-related metadata?  My view is
>> that
>> volatileness does not belong in the alias analysis.  Noalias metadata
>> helps directly with what AA does, so it makes sense to have it there.
>> Volatileness, not so much.
>
> I agree. volatileness and aliasing are orthogonal properties and I'd like not to conflate them. I also don't understand what they have to do with memory dependence. The fact that we promise not to change the number of volatile loads/stores to some location is only something relevant to a transformation that might change that (GVN in this case). Danny, can't we reasonably localize that logic to the transforming passes?
>
Yes.

I actually do not expect a ton to break here if we made getModRefInfo
return Ref/NoModRef for volatile loads.
(I'm going to ignore ordering here because i haven't looked deeply
enough into the models)

For GVN and memdep users, getPointerDependencyFrom already scans all
loads and reports load-load dependencies on volatile ones if the
queryinst is volatile.

MemorySSA can be localized to do what we want.  I can make it consider
them part of the chain, make it do nothing, etc, completely
independent of whatever we choose for getModRefInfo.

A scan of getModRefInfo callers seems that they mostly care about
stores (outside of AA users).

So i'll give it a whirl.