[llvm-bugs] [Bug 32366] New: byte loads aren't fused into unaligned 16-bit load on ARM/AArch64
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Mar 21 18:36:24 PDT 2017
http://bugs.llvm.org/show_bug.cgi?id=32366
Bug ID: 32366
Summary: byte loads aren't fused into unaligned 16-bit load on
ARM/AArch64
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: ARM
Assignee: unassignedbugs at nondot.org
Reporter: simon.hosie at arm.com
CC: llvm-bugs at lists.llvm.org
(also affects AArch64, but I can only tag one component)
clang --target=arm-linux-gneabihf -march=armv7-a -O3 -S -xc -o- - << EOF
#include <stdint.h>
uint16_t ld16(uint8_t const* p) {
uint16_t r;
__builtin_memcpy(&r, p, sizeof(r));
return r;
}
uint16_t ld16_bytes(uint8_t const* p) {
uint16_t r = p[0] | (p[1] << 8);
return r;
}
EOF
gives:
ld16:
ldrh r0, [r0]
bx lr
ld16_bytes:
ldrb r1, [r0]
ldrb r0, [r0, #1]
orr r0, r1, r0, lsl #8
bx lr
For little endian targets I would expect both these functions to turn out the
same (like they do on x86). 32-bit and 64-bit loads seem to be rewritten
already; it's just 16-bit where they diverge.
Note that -march=armv7-a (or similar) is necessary to make the unaligned load
option available.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170322/daa0d069/attachment.html>
More information about the llvm-bugs
mailing list