[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