[LLVMdev] Limit loop vectorizer to SSE

[Joshua Klontz]

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).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131115/aad9554a/attachment.html>