[llvm-bugs] [Bug 35366] New: DAGCombiner: memory aliasing bug
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Nov 20 08:14:11 PST 2017
https://bugs.llvm.org/show_bug.cgi?id=35366
Bug ID: 35366
Summary: DAGCombiner: memory aliasing bug
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedbugs at nondot.org
Reporter: paulsson at linux.vnet.ibm.com
CC: llvm-bugs at lists.llvm.org
Created attachment 19446
--> https://bugs.llvm.org/attachment.cgi?id=19446&action=edit
reduced testcase (llc input)
It seems that Csmith has hit some kind of bug relating to memory aliasing
during DAGCombining. The reduced c-function looks like:
/* --- GLOBAL VARIABLES --- */
static int32_t g_2 = 2;
static int32_t g_5 = -1;
static int32_t g_717 = 0;
static int64_t func_1(void)
{
g_5 = (g_5 & g_2);
if (g_5 != 1)
for (g_2 = 1; (g_2 > 0); --g_2)
return 0;
g_717 = 2;
return (g_5 + g_2 + g_717);
}
/* ---------------------------------------- */
int main (int argc, char* argv[])
{
int print_hash_value = 0;
if (argc == 2 && strcmp(argv[1], "1") == 0) print_hash_value = 1;
platform_main_begin();
crc32_gentab();
func_1();
transparent_crc(g_2, "g_2", print_hash_value);
transparent_crc(g_717, "g_717", print_hash_value);
platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
return 0;
}
func_1() gets inlined into main(). Even though the static global variables are
32 bit signed integers, optimizations have turned g_2 and g_717 into i1
accesses. This is a bit hard for me to follow, but I have trusted sofar that
opt is doing something clever with the constants.
This is the compilers voting on the correct checksum (which also holds with the
reduced test case):
689C3C99: gcc -O0 -march=z10 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: gcc -O1 -march=z10 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: gcc -O0 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: gcc -O1 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: bin/clang -O0 -march=z10 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: bin/clang -O0 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
D2A6FFDC: bin/clang -O3 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
689C3C99: bin/clang -O3 -march=z13 wrong0.c -I/root/csmith/runtime -o a.out -w
-mllvm -disable-basicaa
The test case fails with clang at -O3 (from z10 and up), unless
-disable-basicaa is given.
The interesting block looks like this just before isel:
crc32_gentab.exit:
%44 = load i32, i32* @g_5, align 4, !tbaa !7
%.b1.i = load i1, i1* @g_2, align 4
%45 = select i1 %.b1.i, i32 1, i32 2
%and.i21 = and i32 %45, %44
store i32 %and.i21, i32* @g_5, align 4, !tbaa !7
%cmp.i = icmp eq i32 %and.i21, 1
# select of address for store.
%g_717.sink.i = select i1 %cmp.i, i1* @g_717, i1* @g_2
# store to either @g_717 or @g_2.
store i1 true, i1* %g_717.sink.i, align 4
# load @g_2
%.b = load i1, i1* @g_2, align 4
%conv44 = select i1 %.b, i64 1, i64 2
tail call fastcc void @transparent_crc ...
...
The diff of the .s files in the interesting block look like:
< disable-basicaa (good)
> (bad)
# BB#6: # BB#6:
# LoadAddress: @g_2 into %r2
larl %r2, g_2 larl %r2, g_2
llc %r3, 0(%r2) llc %r3, 0(%r2)
lhi %r4, 2 lhi %r4, 2
chi %r3, 0 chi %r3, 0
larl %r1, g_5 larl %r1, g_5
lochilh %r4, 1 lochilh %r4, 1
n %r4, 0(%r1) n %r4, 0(%r1)
# Load-Address: @g_717 into %r12
larl %r12, g_717 larl %r12, g_717
chi %r4, 1 chi %r4, 1
# Load-On-Condition of @g_717 into address (select implementation)
larl %r1, g_2 | locgre %r2, %r12
locgre %r1, %r12 | mvi 0(%r2), 1
# Move Immediate into @g_717 or @g_2
mvi 0(%r1), 1 <
# Load again @g_2 since MVI may store into it.
# - Missing in bad version with basicaa!
llc %r1, 0(%r2) <
lghi %r2, 2 lghi %r2, 2
chi %r1, 0 | chi %r3, 0
llgfr %r13, %r0 llgfr %r13, %r0
strl %r4, g_5 strl %r4, g_5
locghilh %r2, 1 locghilh %r2, 1
larl %r3, .L.str.1 larl %r3, .L.str.1
lgr %r4, %r13 lgr %r4, %r13
brasl %r14, transparent_crc brasl %r14, transparent_crc
...
The second llc of @g_2 is correctly chained after the store of immediate after
DAG building:
t18: ch = store<ST1[%g_717.sink.i](align=4)> t12, Constant:i1<-1>, t16,
undef:i64
t19: i1,ch = load<LD1[@g_2](align=4)(dereferenceable)> t18,
GlobalAddress:i64<i1* @g_2> 0, undef:i64
When the DAGCombiner visits t19, it calls FindBetterChain(), which calls
GatherAllAliases(). I am not sure about exactly all the details, but
GatherAllAliases() returns no aliases, and the entry node is returned. This
seems to be the point of the error.
The result is that the value of @g_2 from the first load is used instead of the
second load, which is obviously wrong, since the intervening store could be
storing to the same variable, depending on the select result.
bin/llc -mtriple=s390x-linux-gnu -mcpu=z13 ./tc_basicaa.ll
(correct output with -disable-basicaa)
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171120/ae68d5e2/attachment.html>
More information about the llvm-bugs
mailing list