search for: r194876

A fix for this is in r194876. Thanks for reporting 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 i...

I confirm that r194876 fixes the issue, i.e. segfault not caused. My program still passed 16 byte aligned pointers to the function which the loop vectorizer processes successfully: LV: Vector loop of width 8 costs: 1. LV: Selecting VF = : 8. LV: Found a vectorizable loop (8) in func_orig.ll LV: Unroll Factor is 1 Sinc...

...ups ... wheres for the later it will use an aligned move: = vmovaps … vmovups can load from unaligned addresses while vmovaps can not. No, we currently don’t peel loops for alignment. Best, Arnold On Nov 15, 2013, at 7:23 PM, Frank Winter <fwinter at jlab.org> wrote: > I confirm that r194876 fixes the issue, i.e. segfault not caused. > > My program still passed 16 byte aligned pointers to the function > which the loop vectorizer processes successfully: > > LV: Vector loop of width 8 costs: 1. > LV: Selecting VF = : 8. > LV: Found a vectorizable loop (8) in func_o...

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]

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