[BasicAA] test-suite stepanov_v1p2 fails with -disable-basicaa

[Quuxplusone]

Bugzilla Link	PR36830
Status	NEW
Importance	P enhancement
Reported by	Jonas Paulsson (paulsson@linux.vnet.ibm.com)
Reported on	2018-03-21 02:42:30 -0700
Last modified on	2018-03-21 11:03:18 -0700
Version	trunk
Hardware	PC Linux
CC	hfinkel@anl.gov, llvm-bugs@lists.llvm.org, paulsson@linux.vnet.ibm.com, uweigand@de.ibm.com
Fixed by commit(s)
Attachments	stepanov_v1p2.ii (2112 bytes, text/plain)
Blocks
Blocked by
See also

Created attachment 20095
reduced testcase

I have reduced this and found out that the only difference of the succeeding
and failing programs lies in the initialization of two pointers:

        .type   s_end,@object           # @s_end
+       .section        .bss,"aw",@nobits
        .globl  s_end
        .p2align        3
 s_end:
-       .quad   double_array+16000
+       .space  8
        .size   s_end, 8

        .type   t_0,@object             # @t_0
        .globl  t_0
        .p2align        3
 t_0:
-       .quad   double_array
+       .space  8
        .size   t_0, 8

s_end is supposed to point to the end of the array, and t_0 to its first
element.

The code is otherwise identical, and it certainly seems to assume that these
addresses have been initialized correctly.

Not sure exactly why this happens, but it seems to take place before
instruction selection, during the LLVM I/R optimization passes. The difference
after them is also only in the declaration of @s_end and @t_0.

bin/clang -O3 -march=z13 ./stepanov_v1p2.ii -o ./a.out; ./a.out
test 0 passed: 6000.000000 == 6000.000000

bin/clang -O3 -march=z13 ./stepanov_v1p2.ii -o ./a.out -mllvm -disable-basicaa;
./a.out
test 0 failed: 0.000000 != 6000.000000

[Quuxplusone]

Attached stepanov_v1p2.ii (2112 bytes, text/plain): reduced testcase

[Quuxplusone]

You generally can't disable basicaa if you also leave tbaa enabled. Is tbaa also enabled (because many codes have UB but we depend on basicaa overriding tbaa in order to do what the programmer intended)?

[Quuxplusone]

(In reply to Hal Finkel from comment #1)
> You generally can't disable basicaa if you also leave tbaa enabled. Is tbaa
> also enabled (because many codes have UB but we depend on basicaa overriding
> tbaa in order to do what the programmer intended)?

Shouldn't this be fixed then somehow so that if -disable-basicaa is passed,
then tbaa is also automatically disabled?

Anyway, the test case still fails the same way without tbaa like:

bin/clang -O3 -march=z13 ./stepanov_v1p2.ii -o ./a.out; ./a.out
test 0 passed: 6000.000000 == 6000.000000

bin/clang -O3 -march=z13 ./stepanov_v1p2.ii -o ./a.out -mllvm -disable-basicaa -
mllvm -enable-tbaa=false; ./a.out
test 0 failed: 0.000000 != 6000.000000

[Quuxplusone]

(In reply to Jonas Paulsson from comment #2)
> (In reply to Hal Finkel from comment #1)
> > You generally can't disable basicaa if you also leave tbaa enabled. Is tbaa
> > also enabled (because many codes have UB but we depend on basicaa overriding
> > tbaa in order to do what the programmer intended)?
>
> Shouldn't this be fixed then somehow so that if -disable-basicaa is passed,
> then tbaa is also automatically disabled?

No. The programs in question are still incorrect. We're just being less kind ;)

>
> Anyway, the test case still fails the same way without tbaa like:
>
> bin/clang -O3 -march=z13 ./stepanov_v1p2.ii -o ./a.out; ./a.out
> test 0 passed: 6000.000000 == 6000.000000
>
> bin/clang -O3 -march=z13 ./stepanov_v1p2.ii -o ./a.out -mllvm
> -disable-basicaa -mllvm -enable-tbaa=false; ./a.out
> test 0 failed: 0.000000 != 6000.000000

Interesting.