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
On 01/07/2015 06:57 PM, Philip Reames wrote:> 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. :) 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.>
> 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. :)
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev