maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/arm64-be-bitfield.c

13 lines
523 B
C
Raw Normal View History

Use store size instead of alloc size when coercing. Previously, EnterStructPointerForCoercedAccess used Alloc size when determining how to convert. This was problematic, because there were situations were the alloc size was larger than the store size. For example, if the first element of a structure were i24 and the destination type were i32, the old code would generate a GEP and a load i24. The code should compare store sizes to ensure the whole object is loaded. I have attached a test case. This patch modifies the output of arm64-be-bitfield.c test case, but the new IR seems to be equivalent, and after -O3, the compiler generates identical ARM assembly. (asr x0, x0, #54) Patch by Thomas Jablin! llvm-svn: 216722
2014-08-29 18:17:52 +08:00
// RUN: %clang_cc1 -triple aarch64_be-linux-gnu -ffreestanding -emit-llvm -O0 -o - %s | FileCheck --check-prefix IR %s
When doing int<->ptr coercion for big-endian, calculate the shift amount correctly. Previously we calculated the shift amount based upon DataLayout::getTypeAllocSizeInBits. This will only work for legal types - types such as i24 that are created as part of structs for bitfields will return "32" from that function. Change to using getTypeSizeInBits. It turns out that AArch64 didn't run across this problem because it always returned [1 x i64] as the type for a bitfield, whereas ARM64 returns i64 so goes down this (better, but wrong) codepath. llvm-svn: 208231
2014-05-08 01:41:15 +08:00
struct bt3 { signed b2:10; signed b3:10; } b16;
Use store size instead of alloc size when coercing. Previously, EnterStructPointerForCoercedAccess used Alloc size when determining how to convert. This was problematic, because there were situations were the alloc size was larger than the store size. For example, if the first element of a structure were i24 and the destination type were i32, the old code would generate a GEP and a load i24. The code should compare store sizes to ensure the whole object is loaded. I have attached a test case. This patch modifies the output of arm64-be-bitfield.c test case, but the new IR seems to be equivalent, and after -O3, the compiler generates identical ARM assembly. (asr x0, x0, #54) Patch by Thomas Jablin! llvm-svn: 216722
2014-08-29 18:17:52 +08:00
// Get the high 32-bits and then shift appropriately for big-endian.
When doing int<->ptr coercion for big-endian, calculate the shift amount correctly. Previously we calculated the shift amount based upon DataLayout::getTypeAllocSizeInBits. This will only work for legal types - types such as i24 that are created as part of structs for bitfields will return "32" from that function. Change to using getTypeSizeInBits. It turns out that AArch64 didn't run across this problem because it always returned [1 x i64] as the type for a bitfield, whereas ARM64 returns i64 so goes down this (better, but wrong) codepath. llvm-svn: 208231
2014-05-08 01:41:15 +08:00
signed callee_b0f(struct bt3 bp11) {
Use store size instead of alloc size when coercing. Previously, EnterStructPointerForCoercedAccess used Alloc size when determining how to convert. This was problematic, because there were situations were the alloc size was larger than the store size. For example, if the first element of a structure were i24 and the destination type were i32, the old code would generate a GEP and a load i24. The code should compare store sizes to ensure the whole object is loaded. I have attached a test case. This patch modifies the output of arm64-be-bitfield.c test case, but the new IR seems to be equivalent, and after -O3, the compiler generates identical ARM assembly. (asr x0, x0, #54) Patch by Thomas Jablin! llvm-svn: 216722
2014-08-29 18:17:52 +08:00
// IR: callee_b0f(i64 [[ARG:%.*]])
Respect alignment when loading up a coerced function argument Code in CGCall.cpp that loads up function arguments that need to be coerced to a different type may in some cases ignore the fact that the source of the argument is not naturally aligned. This may cause incorrect code to be generated. In some places in CreateCoercedLoad, we already have setAlignment calls to address this, but I ran into one where it was missing, causing wrong code generation on SystemZ. However, in that location, we do not actually know what alignment of the source location we can rely on; the callers do not pass anything to this routine. This is already an issue in other places in CreateCoercedLoad; and the same problem exists for CreateCoercedStore. To avoid pessimising code, and to fix the FIXMEs already in place, this patch also adds an alignment argument to the CreateCoerced* routines and uses it instead of forcing an alignment of 1. The callers are changed to pass in the best information they have. This actually requires changes in a number of existing test cases since we now get better alignment in many places. Differential Revision: http://reviews.llvm.org/D11033 llvm-svn: 241898
2015-07-10 19:31:43 +08:00
// IR: store i64 [[ARG]], i64* [[PTR:%.*]], align 8
Use store size instead of alloc size when coercing. Previously, EnterStructPointerForCoercedAccess used Alloc size when determining how to convert. This was problematic, because there were situations were the alloc size was larger than the store size. For example, if the first element of a structure were i24 and the destination type were i32, the old code would generate a GEP and a load i24. The code should compare store sizes to ensure the whole object is loaded. I have attached a test case. This patch modifies the output of arm64-be-bitfield.c test case, but the new IR seems to be equivalent, and after -O3, the compiler generates identical ARM assembly. (asr x0, x0, #54) Patch by Thomas Jablin! llvm-svn: 216722
2014-08-29 18:17:52 +08:00
// IR: [[BITCAST:%.*]] = bitcast i64* [[PTR]] to i8*
Change memcpy/memove/memset to have dest and source alignment attributes. Summary: This change is step three in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. Step 4) Update Polly to use the new IRBuilder API. Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use getDestAlignment() and getSourceAlignment() instead. Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html Reviewers: rjmccall Subscribers: jyknight, nemanjai, nhaehnle, javed.absar, sbc100, aheejin, kbarton, fedor.sergeev, cfe-commits Differential Revision: https://reviews.llvm.org/D41677 llvm-svn: 323617
2018-01-29 01:27:45 +08:00
// IR: call void @llvm.memcpy.p0i8.p0i8.i64(i8* {{.*}}, i8* align 8 [[BITCAST]], i64 4
When doing int<->ptr coercion for big-endian, calculate the shift amount correctly. Previously we calculated the shift amount based upon DataLayout::getTypeAllocSizeInBits. This will only work for legal types - types such as i24 that are created as part of structs for bitfields will return "32" from that function. Change to using getTypeSizeInBits. It turns out that AArch64 didn't run across this problem because it always returned [1 x i64] as the type for a bitfield, whereas ARM64 returns i64 so goes down this (better, but wrong) codepath. llvm-svn: 208231
2014-05-08 01:41:15 +08:00
return bp11.b2;
}