[llvm-bugs] [Bug 44880] New: Debug invariance in GlobalOpt
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Feb 12 02:49:39 PST 2020
https://bugs.llvm.org/show_bug.cgi?id=44880
Bug ID: 44880
Summary: Debug invariance in GlobalOpt
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedbugs at nondot.org
Reporter: david.stenberg at ericsson.com
CC: jdevlieghere at apple.com, keith.walker at arm.com,
llvm-bugs at lists.llvm.org,
paul_robinson at playstation.sony.com
Created attachment 23121
--> https://bugs.llvm.org/attachment.cgi?id=23121&action=edit
IR reproducer.
After the introduction of "[InstCombine][DebugInfo] Fold constants wrapped in
metadata", some debug invariance started appearing.
Please note that that commit was reverted in
982944525c7706c4dee00042d5b7cf2f0d87804f due to this issue.
C reproducer:
int a, b, c;
static int arr[4];
void foo() {
const int *e[] = {&arr[2]};
const int **f = &e[0];
c = f != foo;
}
int main() {
for (b = 0; b < 4; b++)
a = a ^ arr[b];
return 0;
}
Commands:
$ clang -O3 -g globalopt.c -S -o - -mllvm -disable-debug-info-print -o
with-debug.s
$ clang -O3 globalopt.c -S -o - -mllvm -disable-debug-info-print -o
without-debug.s
$ diff -u without-debug.s with-debug.s
[...]
+ movl arr(%rip), %eax
+ xorl a(%rip), %eax
+ xorl arr+4(%rip), %eax
+ xorl arr+8(%rip), %eax
+ xorl arr+12(%rip), %eax
+ movl %eax, a(%rip)
movl $4, b(%rip)
xorl %eax, %eax
retq
That commit appears to have exposed a pre-existing debug invariance issue in
GlobalOpt.
This can also be reproduced by just running GlobalOpt on the attached IR
reproducer.
$ opt -strip-debug globalopt.ll | opt -S -globalopt -o without-debug.ll
$ opt globalopt.ll | opt -S -globalopt -strip-debug -o with-debug.ll
$ diff without-debug.ll with-debug.ll
[...]
- %xor = xor i32 0, %a.promoted
- %xor.1 = xor i32 0, %xor
- %xor.2 = xor i32 0, %xor.1
- %xor.3 = xor i32 0, %xor.2
+ %0 = load i32, i32* getelementptr inbounds ([4 x i32], [4 x i32]* @arr,
i64 0, i64 0), align 16
+ %xor = xor i32 %0, %a.promoted
+ %1 = load i32, i32* getelementptr inbounds ([4 x i32], [4 x i32]* @arr,
i64 0, i64 1), align 4
+ %xor.1 = xor i32 %1, %xor
+ %2 = load i32, i32* getelementptr inbounds ([4 x i32], [4 x i32]* @arr,
i64 0, i64 2), align 8
+ %xor.2 = xor i32 %2, %xor.1
+ %3 = load i32, i32* getelementptr inbounds ([4 x i32], [4 x i32]* @arr,
i64 0, i64 3), align 4
+ %xor.3 = xor i32 %3, %xor.2
The issue seems to be that the dbg.value intrinsic:
call void @llvm.dbg.value(metadata i64 ptrtoint (i32* getelementptr inbounds
([4 x i32], [4 x i32]* @arr, i64 0, i64 2) to i64), metadata !24, metadata
!DIExpression()), !dbg !32
seems to lead to GlobalStatus::analyzeGlobal() returning true that @arr has its
address taken. This seems to have to do with the analysis bailing out due to
the ptrtoint use of the GEP:
// If the result of the constantexpr isn't pointer type, then we won't
// know to expect it in various places. Just reject early.
if (!isa<PointerType>(CE->getType()))
return true;
--
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/20200212/3bdeda54/attachment.html>
More information about the llvm-bugs
mailing list