[PATCH] Disable load/store vectorization for types with padding bytes
Arnold Schwaighofer
aschwaighofer at apple.com
Wed Apr 24 08:45:29 PDT 2013
After applying the patch I get three failures in the loop vectorizer regression tests.
LLVM :: Transforms/LoopVectorize/X86/constant-vector-operand.ll
LLVM :: Transforms/LoopVectorize/bsd_regex.ll
LLVM :: Transforms/LoopVectorize/minmax_reduction.ll
All of them segfault. The likeliest suspect is:
unsigned ScalarAllocatedSize = DL->getTypeAllocSize(ValTy);
DL might be null:
virtual bool runOnLoop(Loop *L, LPPassManager &LPM) {
// We only vectorize innermost loops.
if (!L->empty())
return false;
SE = &getAnalysis<ScalarEvolution>();
DL = getAnalysisIfAvailable<DataLayout>(); // <<<<
All of the tests above don’t explicitly specify a data layout.
However, we have other code that depends unconditionally on data layout to get the size of types:
InnerLoopVectorizer::createEmptyLoop():
OldInduction = Legal->getInduction();
Type *IdxTy = OldInduction ? OldInduction->getType() :
DL->getIntPtrType(SE->getContext());
and others.
Given this, I think we should bail out if DL == NULL. And fix the tests to include a data layout.
Nadav, what do you think?
On Apr 24, 2013, at 4:19 AM, Daisuke Takahashi <dtakahashi42 at gmail.com> wrote:
> Hi Nadav,
>
>>> + if (0 == Stride || ScalarAllocatedSize != VectorElementSize) {
>> I think that it should be:
>> if (0 == Stride && ScalarAllocatedSize == VectorElementSize) {
> In my understanding, the cost model gives up the vectorization when above conditions are met. My patch says there are two different conditions that the optimizer should not vectorize memory instructions,
> 1. the target pointer is not an array (I suppose, stride == 0),
> 2. the size of array and vector elements are different (the new one).
> Those conditions seems to be independent, and both conditions should be concerned.
>
>> Can you please provide a test case ? Also, if you attach a file to the email it would make it easier apply the patch.
> I apologize for troubling you, I attach both of them on this email. The test case simply checks if there is not bit-casting from x86_fp80 array to vector, because I could not figure out how can it check the wrong "result" when it runs.
>
> Regards,
> Daisuke
>
> <LoopVectorize.cpp.diff><test-x86_fp80-vector-store.ll>
More information about the llvm-commits
mailing list