[PATCH] D26014: [ConstantFold] Get the correct vector type when folding a getelementptr instruction with vector indices
David Majnemer via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 27 17:03:11 PDT 2016
majnemer added inline comments.
================
Comment at: test/Transforms/InstCombine/gep-vector.ll:12-15
+define <8 x i64*> @patatino2() {
+ %el = getelementptr inbounds i64, i64* undef, <8 x i64> undef
+ ret <8 x i64*> %el
+}
----------------
davide wrote:
> I tried to replace this getelemptr with
>
> ```getelementptr inbounds (i64, i64* undef, <8 x i64> undef)```
> but I get a parser error. Is this asimmetry between `getelementptr` constant expression and `getelementptr` instruction intended, or am I missing something?
Seems to be a bug in LLVM.
For example:
> cat t.ll
```
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@GV = global i64 0
define <8 x i64*> @patatino2() {
%el = getelementptr inbounds i64, i64* @GV, <8 x i64> <i64 0, i64 1, i64 0, i64 1, i64 0, i64 1, i64 0, i64 1>
ret <8 x i64*> %el
}
```
> ~/llvm/Debug+Asserts/bin/opt -S t.ll -O2 | ~/llvm/Debug+Asserts/bin/llc -o -
> ~/llvm/Debug+Asserts/bin/llc: <stdin>:10:18: error: getelementptr index type missmatch
> ret <8 x i64*> getelementptr (i64, i64* @GV, <8 x i64> <i64 0, i64 1, i64 0, i64 1, i64 0, i64 1, i64 0, i64 1>)
It passes the verifier but the parser refuses to deal with it. Worth looking into.
https://reviews.llvm.org/D26014
More information about the llvm-commits
mailing list