MemoryDependence and volatile loads

What are the intended semantics of a volatile load when considered as a possible dependency?

Currently, we have a check for isVolatile with a nice comment about being overly conservative. However, this code turns out to be completely dead. :slight_smile: Instead, this case is handled by the !isUnordered block above*. In the case I'm looking at (load PRE in GVN), we fail the queryInst test and return the same result as we would have in the isVolatile block, but there are cases where we allow volatile loads to be bypassed. (Specifically, when we can tell the queryInst isn't volatile.)

When I make it so that a volatile load is treated like a normal load, none of the tests fail. It also results in load PRE bypassing volatile loads which is good for the case I'm looking at, but the lack of any test failures disturbed me a bit. :slight_smile:

I *think* it's perfectly legal to consider a volatile load as a normal load *unless* the query instruction we're testing against is itself volatile. Another way of phrasing this is that volatiles are only ordered with respects to other volatiles. Do others agree?

* For the sake of forthrightness, I was one of the (several) reviewers on change that added this and none of us noticed the possible issue.

Philip

For anyone interested in the topic of this email, I have a patch up for review which tries to be more precise w.r.t. volatile loads encountered when looking for dependencies of a non-volatile load. See http://reviews.llvm.org/D6901

What are the intended semantics of a volatile load when considered as a possible dependency?

Currently, we have a check for isVolatile with a nice comment about being overly conservative. However, this code turns out to be completely dead. :slight_smile: Instead, this case is handled by the !isUnordered block above*. In the case I'm looking at (load PRE in GVN), we fail the queryInst test and return the same result as we would have in the isVolatile block, but there are cases where we allow volatile loads to be bypassed. (Specifically, when we can tell the queryInst isn't volatile.)

It turns out that the code isn't quite dead. It's just only used if a) your asking a block local dependence question and b) your query instruction passes the atomic checks. In that case, the isVolatile check executed and gives you a conservative result. It is dead if called from GVN though.