[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