[llvm-commits] [PATCH] RFC: fix some problems in GeneralHash
Jakob Stoklund Olesen
stoklund at 2pi.dk
Wed Feb 22 19:20:25 PST 2012
On Feb 22, 2012, at 1:22 PM, Chandler Carruth wrote:
> On Wed, Feb 22, 2012 at 1:11 PM, Talin <viridia at gmail.com> wrote:
> So if we're going to be using memcpy
>
> Don't misunderstand -- there will be no actual memcpy in the generated code. This is a mechanism for reading underlying storage with well defined behavior, it'll disappear in the optimizer.
$ cat ur.c
unsigned unaligned_read(const void *p) {
unsigned x;
memcpy(&x, p, sizeof(x));
return x;
}
$ clang -w -O ur.c -S -emit-llvm -o-
define i32 @unaligned_read(i8* nocapture %p) nounwind uwtable readonly ssp {
entry:
%0 = bitcast i8* %p to i32*
%srcval = load i32* %0, align 1
ret i32 %srcval
}
The backends will know what to do with the unaligned load:
$ clang -w -O ur.c -S -o- -arch armv7
_unaligned_read:
ldr r0, [r0]
bx lr
$ clang -w -O ur.c -S -o- -arch armv5
_unaligned_read:
ldrb r1, [r0]
ldrb r2, [r0, #1]
ldrb r3, [r0, #2]
ldrb r0, [r0, #3]
orr r0, r3, r0, lsl #8
orr r1, r1, r2, lsl #8
orr r0, r1, r0, lsl #16
bx lr
/jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120222/ebaa4fc0/attachment.html>
More information about the llvm-commits
mailing list