[LLVMdev] Limit loop vectorizer to SSE

Arnold Schwaighofer aschwaighofer at apple.com
Fri Nov 15 14:03:00 PST 2013


Aha, this is interesting. I think this is indeed a bug.

We start off with a

= load i8

(A value of 0 or an omitted align argument means that the operation has the ABI alignment for the target)

We vectorize this as
= load <32 x i8> 

Which again is assumed to be abi aligned for the type <… i8> which is probably 32byte.


We should be outputting either the abi alignment of the original type or 1 for such memory accesses (where alignment == 0).

= load <32 x i8>, align 1

I think we don’t see this from code coming from clang because it will output “, align #” for most accesses.

Thanks,
Arnold

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).  
> 
> 





More information about the llvm-dev mailing list