search for: 0204h

Hello Jim, Thank you for the response. I may be confused about the alignment rules here. I had been looking at the ARM RVCT Assembler Guide, which seems to indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). Prior to the table, It does mention the accesses need to be "element" aligned, where I took element in this case to mean i16. Anyhow, to make this a little more concrete: void extend(short* a, int* b) { for(int i = 0; i < 8; i++) b[i] = (int)a[i]; } When I c...

...e: > Hello Jim, > > Thank you for the response. I may be confused about the alignment rules here. > I had been looking at the ARM RVCT Assembler Guide, which seems to indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting their table > (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). > Prior to the table, It does mention the accesses need to be "element" aligned, where I took element in this case to mean i16. > > Anyhow, to make this a little more concrete: > > void extend(short* a, int* b) { > for(int i = 0; i < 8; i++) >...

...Jim, >> >> Thank you for the response. I may be confused about the alignment rules here. >> I had been looking at the ARM RVCT Assembler Guide, which seems to indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting their table >> (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >> Prior to the table, It does mention the accesses need to be "element" aligned, where I took element in this case to mean i16. >> >> Anyhow, to make this a little more concrete: >> >> void extend(short* a, int* b) { >> for(int i = 0;...

VLD1 expects a 64-bit aligned address unless the target explicitly days that unaligned loads are OK. For your situation, either the subtarget should set AllowsUnalignedMem to true (if that's accurate), or the load address should be made 64-bit aligned. -Jim On Sep 5, 2012, at 2:42 PM, Peter Couperus <peter.couperus at st.com> wrote: > Hello all, > > I am a first time writer

...im, >> >> Thank you for the response. I may be confused about the alignment rules here. >> I had been looking at the ARM RVCT Assembler Guide, which seems to >> indicate vld1.16 operates on 16-bit aligned data, unless I am misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >> Prior to the table, It does mention the accesses need to be "element" aligned, where I took element in this case to mean i16. >> >> Anyhow, to make this a little more concrete: >> >> void extend(short* a, int* b) { >> for(int i = 0;...

Hello all, I am a first time writer here, but am a happy LLVM tinkerer. It is a pleasure to use :). We have come across some sub-optimal behavior when LLVM lowers loads for vectors with small integers, i.e. load <4 x i16>* %a, align 2, using a sequence of scalar loads rather than a single vld1 on armv7 linux with NEON. Looking at the code in svn, it appears the ARM backend is capable of

...gt; Thank you for the response. I may be confused about the alignment rules > here. >>> I had been looking at the ARM RVCT Assembler Guide, which seems to >>> indicate vld1.16 operates on 16-bit aligned data, unless I am > misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >>> Prior to the table, It does mention the accesses need to be "element" > aligned, where I took element in this case to mean i16. >>> >>> Anyhow, to make this a little more concrete: >>> >>> void extend(short* a, int* b)...

...for the response. I may be confused about the alignment >>> rules > here. >>> I had been looking at the ARM RVCT Assembler Guide, which seems to >>> indicate vld1.16 operates on 16-bit aligned data, unless I am > misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >>> Prior to the table, It does mention the accesses need to be "element" > aligned, where I took element in this case to mean i16. >>> >>> Anyhow, to make this a little more concrete: >>> >>> void extend(short* a, int* b)...

...may be confused about the alignment >>>> rules >> here. >>>> I had been looking at the ARM RVCT Assembler Guide, which seems to >>>> indicate vld1.16 operates on 16-bit aligned data, unless I am >> misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). >>>> Prior to the table, It does mention the accesses need to be "element" >> aligned, where I took element in this case to mean i16. >>>> >>>> Anyhow, to make this a little more concrete: >>>> >>>> void e...

...the alignment > >>>> rules > >> here. > >>>> I had been looking at the ARM RVCT Assembler Guide, which seems to > >>>> indicate vld1.16 operates on 16-bit aligned data, unless I am > >> misinterpreting their table (Table 5-11 in ARM DUI 0204H, pg 5-70,5-71). > >>>> Prior to the table, It does mention the accesses need to be "element" > >> aligned, where I took element in this case to mean i16. > >>>> > >>>> Anyhow, to make this a little more concrete: > >>>>...