llvm dev - Jun 2013 - [LLVMdev] A question w.r.t fence instruction vs. noalias pointer

On 7 June 2013 17:52, Dallman, John <john.dallman at siemens.com>
wrote:
> Is it possible for the debug information to mark all the instructions that
arise
> from a
> language statement as coming from that statement, even though the
instructions may
> be widely scattered?
Yes.
> Instructions whose effects 
> are used in the logic from more than one statement would have to be
included with
> all those statement.
Hmmm, that would be atypical.  You *can* produce legal DWARF to do that, but
it's a little unlikely that any debugger would understand what you meant.
Generally each instruction is associated with a single statement.

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Renato Golin
> I'm not aware Dwarf supports statements, but it does support line and
column
> information, so if the sources are accurate, you can get
"statements" but not as a
> compiler would recognize, just as a string.
DWARF actually doesn't support source *extents*, it assumes the compiler
will map each statement to a single (canonical) source location and associate
each instruction produced for that statement to the same source location.

DWARF "supports statements" in the sense that a compiler can flag an
instruction as an appropriate place to set a breakpoint for a given
statement, i.e. the statement whose canonical source location is
associated with that instruction.

--paulr

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.

However, if I put the fence instruction in a function, such as:

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
  tail call void @barrier(i32 0, i32 1) nounwind
  %val2 = load <2 x float>* %data0, align 8
  store <2 x float> %val2, <2 x float>* %out, align 8
  ret void
}

define  void @barrier(i32, i32) nounwind {
  fence acq_rel
  ret void
}

Then GVN would remove the load after the barrier() call.

I'm not very sure whether this is the correct behavior. In other words,
should a fence instruction be able to prevent noalias pointers in the caller
function from being reordered? If not, then if the barrier() function is later
being inlined, then the fence instruction would be able to prevent the loads
from being moved across it, as in the first example. But then we would get
different behavior depending on whether the function is inlined or not.

I would appreciate it if someone could clarify this for me.

Thanks,
Xiaoyi

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>