[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