Displaying 6 results from an estimated 6 matches for "unaligned_load_store".
2012 Sep 06
0
[LLVMdev] Unaligned vector memory access for ARM/NEON.
...es with less-than-element
alignment. Why would we need a new field?
I was proposing it as a way to keep the current behavior of the
AllowsUnAlignedMem field. Originally I just guarded the use of vld1/vst1 by
testing whether the target has NEON, but then I was getting a failure in
test/CodeGen/ARM/unaligned_load_store.ll because it did not want to see a
vld1 when using the -arm-strict-align even if the target has NEON.
The difference in the flags is between allowing unaligned access for
half-word and word load/stores (e.g. ldr/str) and getting around an
unaligned access for D registers by using vld1.8/vst1.8 t...
2012 Sep 06
2
[LLVMdev] Unaligned vector memory access for ARM/NEON.
...to model the SCTLR.A setting, which also applies to Neon load/stores with less-than-element alignment. Why would we need a new field?
>
> The -arm-strict-align would set both of the fields to false. This would
> retain the behavior that seems to be desired from the
> test/CodeGen/ARM/unaligned_load_store.ll test case.
>
> A bit of a grey area is if we have an unaligned f64 store and
> AllowsElementAlignedNEON is true. We can actually generate a vstr1.8 to
> support this store directly instead of using the target-independent method
> and I think it would be good to do so.
Don't...
2012 Sep 07
2
[LLVMdev] Unaligned vector memory access for ARM/NEON.
...alignment. Why would we need a new field?
>
> I was proposing it as a way to keep the current behavior of the
> AllowsUnAlignedMem field. Originally I just guarded the use of vld1/vst1 by
> testing whether the target has NEON, but then I was getting a failure in
> test/CodeGen/ARM/unaligned_load_store.ll because it did not want to see a
> vld1 when using the -arm-strict-align even if the target has NEON.
I think we could just change the test case. The point of -arm-strict-align is just to avoid relying on hardware or OS support for unaligned accesses. Using vld1.8/vst1.8 instructions woul...
2012 Sep 07
0
[LLVMdev] Unaligned vector memory access for ARM/NEON.
...e need a new field?
> >
> > I was proposing it as a way to keep the current behavior of the
> > AllowsUnAlignedMem field. Originally I just guarded the use of
> > vld1/vst1 by testing whether the target has NEON, but then I was
> > getting a failure in test/CodeGen/ARM/unaligned_load_store.ll because
> > it did not want to see a
> > vld1 when using the -arm-strict-align even if the target has NEON.
>
> I think we could just change the test case. The point of
-arm-strict-align is
> just to avoid relying on hardware or OS support for unaligned accesses.
> Usin...
2012 Sep 06
0
[LLVMdev] Unaligned vector memory access for ARM/NEON.
...ould
be used allow targets to generate vld1/vst1 instructions for element-aligned
accesses. By default it would be set to true for armv7 targets with NEON.
The -arm-strict-align would set both of the fields to false. This would
retain the behavior that seems to be desired from the
test/CodeGen/ARM/unaligned_load_store.ll test case.
A bit of a grey area is if we have an unaligned f64 store and
AllowsElementAlignedNEON is true. We can actually generate a vstr1.8 to
support this store directly instead of using the target-independent method
and I think it would be good to do so.
I have some code to do this that I...
2012 Sep 06
2
[LLVMdev] Unaligned vector memory access for ARM/NEON.
Hello,
Thanks again. We did try overestimating the alignment, and saw the vldr
you reference here.
It looks like a recent change (r161962?) did enable vld1 generation for
this case (great!) on darwin, but not linux.
I'm not sure if the effect of lowering load <4 x i16>* align 2 to
vld1.16 this was intentional in this change or not.
If so, my question is what is the preferable way to