llvm dev - Nov 2018 - Dependence Analysis bug or undefined behavior?

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.)

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181118/636dea06/attachment.html>

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

I think this should be well defined. C11 says

6.5.2.3 Structure and union members
95) If the member used to read the contents of a union object is not the
same as the member last used to
store a value in the object, the appropriate part of the object
representation of the value is reinterpreted
as an object representation in the new type as described in 6.2.6 (a
process sometimes called ‘‘type
punning’’). This might be a trap representation.

(I'm using this pdf file for the text -
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf )

I guess peephole optimizations also can lead to the load/store with
different types (e.g. memcpy to/from an unsigned char array can be removed
if redundant), so the code seems to make sense.

Best Regards,
Juneyoung Lee

On Sun, Nov 18, 2018 at 11:03 PM De Azevedo Piovezan, Felipe via llvm-dev <
llvm-dev at lists.llvm.org> 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.)
>
>
>
> 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181119/0d63fd87/attachment.html>

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>

Thanks for the answers!

I'll try to dig into DA's code to see if I can find anything, but
I'm not familiar with the implementation details of the analysis. If anyone
has pointers, I'd appreciate it.

From: Finkel, Hal J. [mailto:hfinkel at anl.gov]
Sent: Sunday, November 18, 2018 11:32 AM
To: De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan at intel.com>;
llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Dependence Analysis bug or undefined behavior?


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/20181119/77061ba6/attachment.html>