llvm dev - Jun 2013 - [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>
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/20130612/6a6b1ad4/attachment.html>

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>

On Wed, Jun 12, 2013 at 7:28 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com>
wrote:
>  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?
>
So, something like 'asm volatile ("":::"memory")'?

LLVM can and will move noalias loads/stores across an asm statement like
this; it assumes noalias means "nothing inside this function will touch the
memory in question except accesses through this pointer".

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130612/4c7fa718/attachment.html>