Dependence Analysis bug or undefined behavior?

Project Infrastructure LLVM Dev List Archives
1

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!

2

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

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

3

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

4

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.