> To my surprise, clang 6.0 is willing to generate vld1.8 when no
> particular CPU model is specified:
> https://godbolt.org/g/i5PqcQ
This sample for vld1.8 will be valid due to element size aligned.
Also, although this generator generates hardfp abi as default, if using gcc
7 (with -march=armv7
> Thank you. Was [*2] meant to be a different URL?
Ah, correct is the following.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100511_0401_10_en/ric1447333721072.html
and
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0409i/BABDGHIB.html
-- Makoto
On Thu, Mar 29,
On Thu, Mar 29, 2018 at 4:09 AM, Makoto Kato wrote:
> Since SCTLR isn't allowed on userland, there is no way to detect unalignment
> access support without trap. Generally, unalignement access causes SIGBUS,
> so we might get a data from crash reporter. Android armv7-a ABI doesn't
> define that
Since SCTLR isn't allowed on userland, there is no way to detect
unalignment access support without trap. Generally, unalignement access
causes SIGBUS, so we might get a data from crash reporter. Android armv7-a
ABI doesn't define that hardware configuration has to set alignment bit of
SCTLR, so
On Tue, Mar 27, 2018 at 3:44 AM, Henri Sivonen wrote:
> I'm having trouble finding reliable information about the performance
> of unaligned NEON memory access on ARMv7 phones.
>
> What I can find is:
>
> * ARMv7 seems to allow unaligned access to be a trap-to-kernel kind
> of performance disast
5 matches
Mail list logo
