> 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, 2018 at 8:38 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > On Thu, Mar 29, 2018 at 4:09 AM, Makoto Kato <mk...@mozilla.com> 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 hardware configuration has to set alignment bit of SCTLR, so > we > > should consider both unfortunately. > > To my surprise, clang 6.0 is willing to generate vld1.8 when no > particular CPU model is specified: > https://godbolt.org/g/i5PqcQ > > Is unaligned NEON allowed on any ARMv7 CPU without trapping after all > even if unaligned ALU loads/stores might not be? > > > ARM document of Cortex-A8 says [*1], alignment identifier is 64 > > (VLD2.16@64), it requires 2 cycles, but alignment identifier is 128 > > (VLD2.16@128), it is 1 cycle. And on Cortex-A9, unalignment access > requires > > additional cycles [*2]. > ... > > [*1] > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm. > doc.ddi0344h/ch16s06s07.html > > [*2] > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm. > doc.ddi0344h/ch16s06s07.html > > Thank you. Was [*2] meant to be a different URL? > > On Wed, Mar 28, 2018 at 6:36 PM, Gregory Szorc <g...@mozilla.com> wrote: > > Is > > http://fastcompression.blogspot.fr/2015/08/accessing- > unaligned-memory.html > > and/or the comments for MEM_FORCE_MEMORY_ACCESS at > > https://github.com/facebook/zstd/blob/dev/lib/common/mem.h useful? > > Thanks, but unfortunately these don't address my issue. These are > about getting GCC to perform an unaligned load efficiently when the > programmer has already decided to want an unaligned load. > > I'm trying to figure out whether it's worthwhile to spend cycles to > move pointers to alignment if possible or whether it makes sense to > just use unaligned operations unconditionally. (Also, GCC doesn't > matter in my case, since I'm planning Rust code.) > > In non-ARMv7 cases my findings are that moving to alignment doesn't > look empirically worthwhile on aarch64 (tested RPi3 and ThunderX, > which both have in-order cores; should test an out-of-order core, but > documentation supports the empirical results) or on Haswell > (documentation indicates that the key is Nehalem or newer). On Core 2 > Duo, moving to alignment is worthwhile. > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
