If the GEP instructions are going to be vectorized, the indices in those
GEP instructions must be of the same type. Otherwise, the compiler may
crash when trying to build the vector constant.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4170–4171 | I think it's already a fuzzer corner case that we have different types in the bug report example, but let's take that 1 step further: what if the index type in IR is larger than getIntPtrType()? We might illegally truncate a large constant value. Safer to just give up completely if we find mismatched GEP index types? |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4170–4171 | Maybe, just give up if GEP at least one index type is larger than intptr? |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4170–4171 | That should work, but it seems like we are adding code complexity for no real-world reason. Unless I'm misunderstanding - do we have real code / tests where the GEP indexes are different sizes? |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4170–4171 | It does not add a lot of complexity here, just a few additional lines of code. |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4170–4171 | https://llvm.org/docs/LangRef.html#langref-datalayout
|
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4170–4171 | For reference, I think the patch that @xbolva00 mentioned is: (...unfortunately, expandmemcmp is still a codegen pass - D60318 / rL371507 - so that particular case can't be in play yet for the question/concern raised in this patch) Given the LangRef specification, I'm surprised that we're encouraging hard-coding the index size via the Builder API rather than deriving it from the DataLayout. So it seems like we've made a mess, and now we want to deal with that mess here. I still don't see any real-world reason for this patch to try so hard, but if we insist on it, then we should be using: DL->getIndexTypeSizeInBits() ? |
I think it's already a fuzzer corner case that we have different types in the bug report example, but let's take that 1 step further: what if the index type in IR is larger than getIntPtrType()? We might illegally truncate a large constant value.
Safer to just give up completely if we find mismatched GEP index types?