[LLVMdev] A question w.r.t fence instruction vs. noalias pointer

[Guo, Xiaoyi]

So fence only forces ordering of atomic instructions.

Let me change my question then.

If I have a target-specific intrinsic which forces ordering of ordinary load/store instructions. Then should it also force ordering of load/stores to noalias pointers in caller functions?

Thanks,
Xiaoyi

From: Eli Friedman [mailto:eli.friedman at gmail.com]
Sent: Wednesday, June 12, 2013 7:06 PM
To: Guo, Xiaoyi
Cc: LLVM Dev
Subject: Re: [LLVMdev] A question w.r.t fence instruction vs. noalias pointer


On Wed, Jun 12, 2013 at 6:17 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com<mailto:Xiaoyi.Guo at amd.com>> wrote:
Hi,

I have the following test case:

define  void @foo(<2 x float>* noalias nocapture %out, <2 x float>* noalias nocapture %data0) nounwind {
entry:
  %val1 = load <2 x float>* %data0, align 8
  store <2 x float> %val1, <2 x float>* %out, align 8
  fence acq_rel
  %val2 = load <2 x float>* %data0, align 8
  store <2 x float> %val2, <2 x float>* %out, align 8
  ret void
}

If I run it though GVN with BasicAliasAnalysis, GVN does not remove the load after the fence.

According to the LLVM atomics rules, the compiler is actually completely free to either hoist the fence to the top of the function or sink it to the bottom because your loads/stores aren't atomic.  The fact that LLVM doesn't actually do this is just because I didn't put much effort into alias analysis for fences; see http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Analysis/AliasAnalysis.h?revision=182755&view=markup#l431 .
-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130613/5cad899f/attachment.html>