[LLVMdev] Limit loop vectorizer to SSE
Hal Finkel
hfinkel at anl.gov
Fri Nov 15 14:18:27 PST 2013
----- Original Message -----
> From: "Arnold Schwaighofer" <aschwaighofer at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Joshua Klontz" <josh.klontz at gmail.com>
> Sent: Friday, November 15, 2013 4:15:03 PM
> Subject: Re: [LLVMdev] Limit loop vectorizer to SSE
>
> Yes,
>
> I was just about to send out:
>
> DL->getABITypeAlignment(ScalarDataTy);
>
> The question is:
>
> “… ABI alignment for the target …"
>
> is that
>
> getPrefTypeAlignment
> or
> getABITypeAlignment
>
> I would have thought the latter.
Yep; I think you're right (or call both and take the minimum).
-Hal
>
>
> On Nov 15, 2013, at 4:12 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> > ----- Original Message -----
> >> From: "Arnold Schwaighofer" <aschwaighofer at apple.com>
> >> To: "Joshua Klontz" <josh.klontz at gmail.com>
> >> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>
> >> Sent: Friday, November 15, 2013 4:05:53 PM
> >> Subject: Re: [LLVMdev] Limit loop vectorizer to SSE
> >>
> >>
> >> Something like:
> >>
> >> index 6db7f68..68564cb 100644
> >> --- a/lib/Transforms/Vectorize/LoopVectorize.cpp
> >> +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp
> >> @@ -1208,6 +1208,8 @@ void
> >> InnerLoopVectorizer::vectorizeMemoryInstruction(Instr
> >> Type *DataTy = VectorType::get(ScalarDataTy, VF);
> >> Value *Ptr = LI ? LI->getPointerOperand() :
> >> SI->getPointerOperand();
> >> unsigned Alignment = LI ? LI->getAlignment() :
> >> SI->getAlignment();
> >> + if (Alignment == 0)
> >> + Alignment = 1;
> >
> > That may be conservatively correct, but I don't think it is really
> > right. An alignment of 0 is supposed to mean the platform default
> > alignment (IIRC, DataLayout::getPrefTypeAlignment tells you what
> > it is).
> >
> > -Hal
> >
> >> unsigned AddressSpace =
> >> Ptr->getType()->getPointerAddressSpace();
> >> unsigned ScalarAllocatedSize =
> >> DL->getTypeAllocSize(ScalarDataTy);
> >> unsigned VectorElementSize = DL->getTypeStoreSize(DataTy)/VF;
> >>
> >> Should fix this.
> >>
> >> On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com>
> >> wrote:
> >>
> >>> Nadav,
> >>>
> >>> I believe aligned accesses to unaligned pointers is precisely the
> >>> issue. Consider the function `add_u8S` before[1] and after[2] the
> >>> loop vectorizer pass. There is no alignment assumption associated
> >>> with %kernel_data prior to vectorization. I can't tell if it's
> >>> the
> >>> loop vectorizer or the codegen at fault, but the alignment
> >>> assumption seems to sneak in somewhere.
> >>>
> >>> v/r,
> >>> Josh
> >>>
> >>> [1] http://pastebin.com/kc95WtGG
> >>> [2] http://pastebin.com/VY3ZLVJK
> >>>
> >>>
> >>> On Fri, Nov 15, 2013 at 3:58 PM, Nadav Rotem <nrotem at apple.com>
> >>> wrote:
> >>>
> >>> On Nov 15, 2013, at 12:36 PM, Renato Golin
> >>> <renato.golin at linaro.org> wrote:
> >>>
> >>>> On 15 November 2013 20:24, Joshua Klontz <josh.klontz at gmail.com>
> >>>> wrote:
> >>>> Agreed, is there a pass that will insert a runtime alignment
> >>>> check? Also, what's the easiest way to get at
> >>>> TargetTransformInfo::getRegisterBitWidth() so I don't have to
> >>>> hard code 32? Thanks!
> >>>>
> >>>> I think that's a fair question, and it's about safety. If you're
> >>>> getting this on the JIT, means we may be generating unsafe
> >>>> transformations on the vectorizer.
> >>>>
> >>>> Arnold, Nadav, I don't remember seeing code to generate any
> >>>> run-time alignment checks on the incoming pointer, is there such
> >>>> a thing? If not, shouldn't we add one?
> >>>
> >>>
> >>> If the the vectorizer generates aligned memory accesses to
> >>> unaligned addresses then this is a serious bug. But I don’t
> >>> think
> >>> that Josh said that the vectorizer generated aligned accesses to
> >>> unaligned pointers.
> >>>
> >>> There is no point in LLVM checking for alignment because if the
> >>> memory is unaligned then the program will crash. Users who want
> >>> to crash with a readable error message can simply write code that
> >>> checks the pointer (by masking the high bits and comparing to
> >>> zero).
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev
mailing list