[llvm-bugs] [Bug 39908] New: [InstCombine] GEP is wrongly optimized for 32-bit targets
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Dec 7 02:41:17 PST 2018
https://bugs.llvm.org/show_bug.cgi?id=39908
Bug ID: 39908
Summary: [InstCombine] GEP is wrongly optimized for 32-bit
targets
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: mati865 at gmail.com
CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
Forwarding https://github.com/rust-lang/rust/issues/52026
Minimal example by neivv and rkruppe:
```
target datalayout = "p:32:32"
%S = type { [2 x i32] }
define i1 @foo([0 x %S]* %p, i32 %n) {
%start.cast = bitcast [0 x %S]* %p to %S*
%end = getelementptr inbounds [0 x %S], [0 x %S]* %p, i32 0, i32 %n, i32 0,
i32 0
%end.cast = bitcast i32* %end to %S*
%last = getelementptr inbounds %S, %S* %end.cast, i32 -1
%cmp = icmp eq %S* %last, %start.cast
ret i1 %cmp
}
```
GodBolt link: https://godbolt.org/z/C84Axg
For 32 bit targets it turns to:
define i1 @foo([0 x %S]* %p, i32 %n) {
%cmp = icmp eq i32 %n, -536870911
ret i1 %cmp
}
While 64 bit targets are optimized correctly:
define i1 @foo([0 x %S]* %p, i32 %n) {
%cmp = icmp eq i32 %n, 1
ret i1 %cmp
}
Explanation of the issue from
https://github.com/rust-lang/rust/issues/52026#issuecomment-403628144:
In this issue, the code is comparing roughly (S *)slice_start == (S
*)slice_start + slice_len - 1.
This function is extracting the constant byte offset, -8, and dividing it by 8,
sizeof(S). However, before that, compiling to a 32-bit target, the values are
masked by PtrSizeMask 0xFFFFFFFF, which discards the sign bit of int64 and
gives +4294967288, which divided by 8 is the same 536870911 which ends up being
in the result.
--
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/20181207/18fce304/attachment.html>
More information about the llvm-bugs
mailing list