[llvm-dev] Dependence Analysis bug or undefined behavior?

Finkel, Hal J. via llvm-dev llvm-dev at lists.llvm.org
Sun Nov 18 08:32:21 PST 2018


On 11/18/2018 08:02 AM, De Azevedo Piovezan, Felipe via llvm-dev wrote:
Hi,

Does this kind of IR have “undefined behavior”  under LLVM semantics or is it acceptable?

(TLDR: a store of i64 at offset n, followed by a load of i32 at offset n+1.)

Yes, this is well-defined at the IR level. It might have been undefined at the source level, and that might have been translated into TBAA metadata at the LLVM level which would have rendered it undefined at the IR level, but I see no aliasing metadata here.

 -Hal


define void @foo(i32* %A, i64 %n) {
entry:
  %arrayidx = getelementptr inbounds i32, i32* %A, i64 %n
  %arrayidx_cast = bitcast i32* %arrayidx to i64*
  store i64 0, i64* %arrayidx_cast, align 4
  %add1 = add i64 %n, 1
  %arrayidx2 = getelementptr inbounds i32, i32* %A, i64 %add1
  %0 = load i32, i32* %arrayidx2, align 4
  ret void
}

The result of Dependence Analysis is:

opt -analyze -da BitCasts.ll
Printing analysis 'Dependence Analysis' for function 'z0':
da analyze - none!          <<< this is between the store and itself, ok to be “none”.
da analyze - none!          <<< this is between the store and the load!!!
da analyze - none!          <<< this is between the load and itself, ok to be “none”.

Is dependence analysis right or wrong? This IR likely comes from some C++ code doing funny things with unions…

Thanks!

--
Felipe de Azevedo Piovezan




_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181118/88e10b87/attachment.html>


More information about the llvm-dev mailing list