2010-04-22 10:35:46 +08:00
|
|
|
// RUN: %clang_cc1 -emit-llvm -triple x86_64 -O3 -o %t.opt.ll %s \
|
2013-07-13 06:30:03 +08:00
|
|
|
// RUN: -fdump-record-layouts > %t.dump.txt
|
2010-04-22 10:35:46 +08:00
|
|
|
// RUN: FileCheck -check-prefix=CHECK-RECORD < %t.dump.txt %s
|
|
|
|
// RUN: FileCheck -check-prefix=CHECK-OPT < %t.opt.ll %s
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
|
|
|
|
/****/
|
|
|
|
|
2010-04-22 10:35:46 +08:00
|
|
|
// Check that we don't read off the end a packed 24-bit structure.
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
// PR6176
|
|
|
|
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: *** Dumping IRgen Record Layout
|
2013-01-31 09:44:26 +08:00
|
|
|
// CHECK-RECORD: Record: RecordDecl{{.*}}s0
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: Layout: <CGRecordLayout
|
Complete Rewrite of CGRecordLayoutBuilder
CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of
existing before ASTRecordLayoutBuilder. It redundantly performed many
layout operations that are now performed by ASTRecordLayoutBuilder and
asserted that the results were the same. With the addition of support
for the MS-ABI, such as placement of vbptrs, vtordisps, different
bitfield layout and a variety of other features, CGRecordLayoutBuilder
was growing unwieldy in its redundancy.
This patch re-architects CGRecordLayoutBuilder to not perform any
redundant layout but rather, as directly as possible, lower an
ASTRecordLayout to an llvm::type. The new architecture is significantly
smaller and simpler than the CGRecordLayoutBuilder and contains fewer
ABI-specific code paths. It's also one pass.
The architecture of the new system is described in the comments. For the
most part, the new system simply takes all of the fields and bases from
an ASTRecordLayout, sorts them, inserts padding and dumps a record.
Bitfields, unions and primary virtual bases make this process a bit more
complicated. See the inline comments.
In addition, this patch updates a few lit tests due to the fact that the
new system computes more accurate llvm types than CGRecordLayoutBuilder.
Each change is commented individually in the review.
Differential Revision: http://llvm-reviews.chandlerc.com/D2795
llvm-svn: 201907
2014-02-22 07:49:50 +08:00
|
|
|
// CHECK-RECORD: LLVMType:%struct.s0 = type { [3 x i8] }
|
2010-08-23 05:01:12 +08:00
|
|
|
// CHECK-RECORD: IsZeroInitializable:1
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: BitFields:[
|
Respect alignment of nested bitfields
tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test:
struct XBitfield {
unsigned b1 : 10;
unsigned b2 : 12;
unsigned b3 : 10;
};
struct YBitfield {
char x;
struct XBitfield y;
} __attribute((packed));
struct YBitfield gbitfield;
unsigned test7() {
// CHECK: @test7
// CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4
return gbitfield.y.b2;
}
The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single
i32 is of course possible, but that still doesn't make it 4-byte aligned as
it remains packed at offset 1 in the surrounding gbitfield object.
This alignment was changed by commit r169489, which also introduced changes
to bitfield access code in CGExpr.cpp. Code before that change used to take
into account *both* the alignment of the field to be accessed within the
current struct, *and* the alignment of that outer struct itself; this logic
was removed by the above commit.
Neglecting to consider both values can cause incorrect code to be generated
(I've seen an unaligned access crash on SystemZ due to this bug).
In order to always use the best known alignment value, this patch removes
the CGBitFieldInfo::StorageAlignment member and replaces it with a
StorageOffset member specifying the offset from the start of the surrounding
struct to the bitfield's underlying storage. This offset can then be combined
with the best-known alignment for a bitfield access lvalue to determine the
alignment to use when accessing the bitfield's storage.
Differential Revision: http://reviews.llvm.org/D11034
llvm-svn: 241916
2015-07-11 01:30:00 +08:00
|
|
|
// CHECK-RECORD: <CGBitFieldInfo Offset:0 Size:24 IsSigned:1 StorageSize:24 StorageOffset:0>
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
struct __attribute((packed)) s0 {
|
|
|
|
int f0 : 24;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct s0 g0 = { 0xdeadbeef };
|
|
|
|
|
|
|
|
int f0_load(struct s0 *a0) {
|
|
|
|
int size_check[sizeof(struct s0) == 3 ? 1 : -1];
|
|
|
|
return a0->f0;
|
|
|
|
}
|
|
|
|
int f0_store(struct s0 *a0) {
|
|
|
|
return (a0->f0 = 1);
|
|
|
|
}
|
|
|
|
int f0_reload(struct s0 *a0) {
|
|
|
|
return (a0->f0 += 1);
|
|
|
|
}
|
|
|
|
|
2013-08-15 14:47:53 +08:00
|
|
|
// CHECK-OPT-LABEL: define i64 @test_0()
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
// CHECK-OPT: ret i64 1
|
|
|
|
// CHECK-OPT: }
|
|
|
|
unsigned long long test_0() {
|
|
|
|
struct s0 g0 = { 0xdeadbeef };
|
|
|
|
unsigned long long res = 0;
|
|
|
|
res ^= g0.f0;
|
|
|
|
res ^= f0_load(&g0) ^ f0_store(&g0) ^ f0_reload(&g0);
|
|
|
|
res ^= g0.f0;
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/****/
|
|
|
|
|
|
|
|
// PR5591
|
|
|
|
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: *** Dumping IRgen Record Layout
|
2013-01-31 09:44:26 +08:00
|
|
|
// CHECK-RECORD: Record: RecordDecl{{.*}}s1
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: Layout: <CGRecordLayout
|
Complete Rewrite of CGRecordLayoutBuilder
CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of
existing before ASTRecordLayoutBuilder. It redundantly performed many
layout operations that are now performed by ASTRecordLayoutBuilder and
asserted that the results were the same. With the addition of support
for the MS-ABI, such as placement of vbptrs, vtordisps, different
bitfield layout and a variety of other features, CGRecordLayoutBuilder
was growing unwieldy in its redundancy.
This patch re-architects CGRecordLayoutBuilder to not perform any
redundant layout but rather, as directly as possible, lower an
ASTRecordLayout to an llvm::type. The new architecture is significantly
smaller and simpler than the CGRecordLayoutBuilder and contains fewer
ABI-specific code paths. It's also one pass.
The architecture of the new system is described in the comments. For the
most part, the new system simply takes all of the fields and bases from
an ASTRecordLayout, sorts them, inserts padding and dumps a record.
Bitfields, unions and primary virtual bases make this process a bit more
complicated. See the inline comments.
In addition, this patch updates a few lit tests due to the fact that the
new system computes more accurate llvm types than CGRecordLayoutBuilder.
Each change is commented individually in the review.
Differential Revision: http://llvm-reviews.chandlerc.com/D2795
llvm-svn: 201907
2014-02-22 07:49:50 +08:00
|
|
|
// CHECK-RECORD: LLVMType:%struct.s1 = type { [3 x i8] }
|
2010-08-23 05:01:12 +08:00
|
|
|
// CHECK-RECORD: IsZeroInitializable:1
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: BitFields:[
|
Respect alignment of nested bitfields
tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test:
struct XBitfield {
unsigned b1 : 10;
unsigned b2 : 12;
unsigned b3 : 10;
};
struct YBitfield {
char x;
struct XBitfield y;
} __attribute((packed));
struct YBitfield gbitfield;
unsigned test7() {
// CHECK: @test7
// CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4
return gbitfield.y.b2;
}
The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single
i32 is of course possible, but that still doesn't make it 4-byte aligned as
it remains packed at offset 1 in the surrounding gbitfield object.
This alignment was changed by commit r169489, which also introduced changes
to bitfield access code in CGExpr.cpp. Code before that change used to take
into account *both* the alignment of the field to be accessed within the
current struct, *and* the alignment of that outer struct itself; this logic
was removed by the above commit.
Neglecting to consider both values can cause incorrect code to be generated
(I've seen an unaligned access crash on SystemZ due to this bug).
In order to always use the best known alignment value, this patch removes
the CGBitFieldInfo::StorageAlignment member and replaces it with a
StorageOffset member specifying the offset from the start of the surrounding
struct to the bitfield's underlying storage. This offset can then be combined
with the best-known alignment for a bitfield access lvalue to determine the
alignment to use when accessing the bitfield's storage.
Differential Revision: http://reviews.llvm.org/D11034
llvm-svn: 241916
2015-07-11 01:30:00 +08:00
|
|
|
// CHECK-RECORD: <CGBitFieldInfo Offset:0 Size:10 IsSigned:1 StorageSize:24 StorageOffset:0>
|
|
|
|
// CHECK-RECORD: <CGBitFieldInfo Offset:10 Size:10 IsSigned:1 StorageSize:24 StorageOffset:0>
|
2010-04-22 10:35:46 +08:00
|
|
|
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
#pragma pack(push)
|
|
|
|
#pragma pack(1)
|
|
|
|
struct __attribute((packed)) s1 {
|
|
|
|
signed f0 : 10;
|
|
|
|
signed f1 : 10;
|
|
|
|
};
|
|
|
|
#pragma pack(pop)
|
|
|
|
|
|
|
|
struct s1 g1 = { 0xdeadbeef, 0xdeadbeef };
|
|
|
|
|
|
|
|
int f1_load(struct s1 *a0) {
|
|
|
|
int size_check[sizeof(struct s1) == 3 ? 1 : -1];
|
|
|
|
return a0->f1;
|
|
|
|
}
|
|
|
|
int f1_store(struct s1 *a0) {
|
|
|
|
return (a0->f1 = 1234);
|
|
|
|
}
|
|
|
|
int f1_reload(struct s1 *a0) {
|
|
|
|
return (a0->f1 += 1234);
|
|
|
|
}
|
|
|
|
|
2013-08-15 14:47:53 +08:00
|
|
|
// CHECK-OPT-LABEL: define i64 @test_1()
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
// CHECK-OPT: ret i64 210
|
|
|
|
// CHECK-OPT: }
|
|
|
|
unsigned long long test_1() {
|
|
|
|
struct s1 g1 = { 0xdeadbeef, 0xdeadbeef };
|
|
|
|
unsigned long long res = 0;
|
|
|
|
res ^= g1.f0 ^ g1.f1;
|
|
|
|
res ^= f1_load(&g1) ^ f1_store(&g1) ^ f1_reload(&g1);
|
|
|
|
res ^= g1.f0 ^ g1.f1;
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/****/
|
|
|
|
|
2010-04-22 10:35:46 +08:00
|
|
|
// Check that we don't access beyond the bounds of a union.
|
|
|
|
//
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
// PR5567
|
|
|
|
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: *** Dumping IRgen Record Layout
|
2013-01-31 09:44:26 +08:00
|
|
|
// CHECK-RECORD: Record: RecordDecl{{.*}}u2
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: Layout: <CGRecordLayout
|
Complete Rewrite of CGRecordLayoutBuilder
CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of
existing before ASTRecordLayoutBuilder. It redundantly performed many
layout operations that are now performed by ASTRecordLayoutBuilder and
asserted that the results were the same. With the addition of support
for the MS-ABI, such as placement of vbptrs, vtordisps, different
bitfield layout and a variety of other features, CGRecordLayoutBuilder
was growing unwieldy in its redundancy.
This patch re-architects CGRecordLayoutBuilder to not perform any
redundant layout but rather, as directly as possible, lower an
ASTRecordLayout to an llvm::type. The new architecture is significantly
smaller and simpler than the CGRecordLayoutBuilder and contains fewer
ABI-specific code paths. It's also one pass.
The architecture of the new system is described in the comments. For the
most part, the new system simply takes all of the fields and bases from
an ASTRecordLayout, sorts them, inserts padding and dumps a record.
Bitfields, unions and primary virtual bases make this process a bit more
complicated. See the inline comments.
In addition, this patch updates a few lit tests due to the fact that the
new system computes more accurate llvm types than CGRecordLayoutBuilder.
Each change is commented individually in the review.
Differential Revision: http://llvm-reviews.chandlerc.com/D2795
llvm-svn: 201907
2014-02-22 07:49:50 +08:00
|
|
|
// CHECK-RECORD: LLVMType:%union.u2 = type { i8 }
|
2010-08-23 05:01:12 +08:00
|
|
|
// CHECK-RECORD: IsZeroInitializable:1
|
2010-04-22 10:35:46 +08:00
|
|
|
// CHECK-RECORD: BitFields:[
|
Respect alignment of nested bitfields
tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test:
struct XBitfield {
unsigned b1 : 10;
unsigned b2 : 12;
unsigned b3 : 10;
};
struct YBitfield {
char x;
struct XBitfield y;
} __attribute((packed));
struct YBitfield gbitfield;
unsigned test7() {
// CHECK: @test7
// CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4
return gbitfield.y.b2;
}
The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single
i32 is of course possible, but that still doesn't make it 4-byte aligned as
it remains packed at offset 1 in the surrounding gbitfield object.
This alignment was changed by commit r169489, which also introduced changes
to bitfield access code in CGExpr.cpp. Code before that change used to take
into account *both* the alignment of the field to be accessed within the
current struct, *and* the alignment of that outer struct itself; this logic
was removed by the above commit.
Neglecting to consider both values can cause incorrect code to be generated
(I've seen an unaligned access crash on SystemZ due to this bug).
In order to always use the best known alignment value, this patch removes
the CGBitFieldInfo::StorageAlignment member and replaces it with a
StorageOffset member specifying the offset from the start of the surrounding
struct to the bitfield's underlying storage. This offset can then be combined
with the best-known alignment for a bitfield access lvalue to determine the
alignment to use when accessing the bitfield's storage.
Differential Revision: http://reviews.llvm.org/D11034
llvm-svn: 241916
2015-07-11 01:30:00 +08:00
|
|
|
// CHECK-RECORD: <CGBitFieldInfo Offset:0 Size:3 IsSigned:0 StorageSize:8 StorageOffset:0>
|
2010-04-22 10:35:46 +08:00
|
|
|
|
|
|
|
union __attribute__((packed)) u2 {
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
unsigned long long f0 : 3;
|
|
|
|
};
|
|
|
|
|
|
|
|
union u2 g2 = { 0xdeadbeef };
|
|
|
|
|
|
|
|
int f2_load(union u2 *a0) {
|
|
|
|
return a0->f0;
|
|
|
|
}
|
|
|
|
int f2_store(union u2 *a0) {
|
|
|
|
return (a0->f0 = 1234);
|
|
|
|
}
|
|
|
|
int f2_reload(union u2 *a0) {
|
|
|
|
return (a0->f0 += 1234);
|
|
|
|
}
|
|
|
|
|
2013-08-15 14:47:53 +08:00
|
|
|
// CHECK-OPT-LABEL: define i64 @test_2()
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
// CHECK-OPT: ret i64 2
|
|
|
|
// CHECK-OPT: }
|
|
|
|
unsigned long long test_2() {
|
|
|
|
union u2 g2 = { 0xdeadbeef };
|
|
|
|
unsigned long long res = 0;
|
|
|
|
res ^= g2.f0;
|
|
|
|
res ^= f2_load(&g2) ^ f2_store(&g2) ^ f2_reload(&g2);
|
|
|
|
res ^= g2.f0;
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
// PR5039
|
|
|
|
|
|
|
|
struct s3 {
|
|
|
|
long long f0 : 32;
|
|
|
|
long long f1 : 32;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct s3 g3 = { 0xdeadbeef, 0xdeadbeef };
|
|
|
|
|
|
|
|
int f3_load(struct s3 *a0) {
|
|
|
|
a0->f0 = 1;
|
|
|
|
return a0->f0;
|
|
|
|
}
|
|
|
|
int f3_store(struct s3 *a0) {
|
|
|
|
a0->f0 = 1;
|
|
|
|
return (a0->f0 = 1234);
|
|
|
|
}
|
|
|
|
int f3_reload(struct s3 *a0) {
|
|
|
|
a0->f0 = 1;
|
|
|
|
return (a0->f0 += 1234);
|
|
|
|
}
|
|
|
|
|
2013-08-15 14:47:53 +08:00
|
|
|
// CHECK-OPT-LABEL: define i64 @test_3()
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
// CHECK-OPT: ret i64 -559039940
|
|
|
|
// CHECK-OPT: }
|
|
|
|
unsigned long long test_3() {
|
|
|
|
struct s3 g3 = { 0xdeadbeef, 0xdeadbeef };
|
|
|
|
unsigned long long res = 0;
|
|
|
|
res ^= g3.f0 ^ g3.f1;
|
|
|
|
res ^= f3_load(&g3) ^ f3_store(&g3) ^ f3_reload(&g3);
|
|
|
|
res ^= g3.f0 ^ g3.f1;
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
// This is a case where the bitfield access will straddle an alignment boundary
|
|
|
|
// of its underlying type.
|
|
|
|
|
|
|
|
struct s4 {
|
|
|
|
unsigned f0 : 16;
|
|
|
|
unsigned f1 : 28 __attribute__ ((packed));
|
|
|
|
};
|
|
|
|
|
|
|
|
struct s4 g4 = { 0xdeadbeef, 0xdeadbeef };
|
|
|
|
|
|
|
|
int f4_load(struct s4 *a0) {
|
|
|
|
return a0->f0 ^ a0->f1;
|
|
|
|
}
|
|
|
|
int f4_store(struct s4 *a0) {
|
|
|
|
return (a0->f0 = 1234) ^ (a0->f1 = 5678);
|
|
|
|
}
|
|
|
|
int f4_reload(struct s4 *a0) {
|
|
|
|
return (a0->f0 += 1234) ^ (a0->f1 += 5678);
|
|
|
|
}
|
|
|
|
|
2013-08-15 14:47:53 +08:00
|
|
|
// CHECK-OPT-LABEL: define i64 @test_4()
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
// CHECK-OPT: ret i64 4860
|
|
|
|
// CHECK-OPT: }
|
|
|
|
unsigned long long test_4() {
|
|
|
|
struct s4 g4 = { 0xdeadbeef, 0xdeadbeef };
|
|
|
|
unsigned long long res = 0;
|
|
|
|
res ^= g4.f0 ^ g4.f1;
|
|
|
|
res ^= f4_load(&g4) ^ f4_store(&g4) ^ f4_reload(&g4);
|
|
|
|
res ^= g4.f0 ^ g4.f1;
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
struct s5 {
|
|
|
|
unsigned f0 : 2;
|
|
|
|
_Bool f1 : 1;
|
|
|
|
_Bool f2 : 1;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct s5 g5 = { 0xdeadbeef, 0xdeadbeef };
|
|
|
|
|
|
|
|
int f5_load(struct s5 *a0) {
|
|
|
|
return a0->f0 ^ a0->f1;
|
|
|
|
}
|
|
|
|
int f5_store(struct s5 *a0) {
|
|
|
|
return (a0->f0 = 0xF) ^ (a0->f1 = 0xF) ^ (a0->f2 = 0xF);
|
|
|
|
}
|
|
|
|
int f5_reload(struct s5 *a0) {
|
|
|
|
return (a0->f0 += 0xF) ^ (a0->f1 += 0xF) ^ (a0->f2 += 0xF);
|
|
|
|
}
|
|
|
|
|
2013-08-15 14:47:53 +08:00
|
|
|
// CHECK-OPT-LABEL: define i64 @test_5()
|
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
2010-04-15 11:47:33 +08:00
|
|
|
// CHECK-OPT: ret i64 2
|
|
|
|
// CHECK-OPT: }
|
|
|
|
unsigned long long test_5() {
|
|
|
|
struct s5 g5 = { 0xdeadbeef, 0xdeadbeef, 0xdeadbeef };
|
|
|
|
unsigned long long res = 0;
|
|
|
|
res ^= g5.f0 ^ g5.f1 ^ g5.f2;
|
|
|
|
res ^= f5_load(&g5) ^ f5_store(&g5) ^ f5_reload(&g5);
|
|
|
|
res ^= g5.f0 ^ g5.f1 ^ g5.f2;
|
|
|
|
return res;
|
|
|
|
}
|
2010-04-18 05:52:22 +08:00
|
|
|
|
2010-04-21 01:52:30 +08:00
|
|
|
/***/
|
|
|
|
|
|
|
|
struct s6 {
|
2015-09-15 05:27:36 +08:00
|
|
|
unsigned f0 : 2;
|
2010-04-18 05:52:22 +08:00
|
|
|
};
|
|
|
|
|
2010-04-21 01:52:30 +08:00
|
|
|
struct s6 g6 = { 0xF };
|
|
|
|
|
|
|
|
int f6_load(struct s6 *a0) {
|
|
|
|
return a0->f0;
|
|
|
|
}
|
|
|
|
int f6_store(struct s6 *a0) {
|
|
|
|
return a0->f0 = 0x0;
|
|
|
|
}
|
|
|
|
int f6_reload(struct s6 *a0) {
|
|
|
|
return (a0->f0 += 0xF);
|
|
|
|
}
|
|
|
|
|
2013-08-15 14:47:53 +08:00
|
|
|
// CHECK-OPT-LABEL: define zeroext i1 @test_6()
|
2010-04-21 01:52:30 +08:00
|
|
|
// CHECK-OPT: ret i1 true
|
2010-04-18 05:52:22 +08:00
|
|
|
// CHECK-OPT: }
|
|
|
|
_Bool test_6() {
|
2010-04-21 01:52:30 +08:00
|
|
|
struct s6 g6 = { 0xF };
|
|
|
|
unsigned long long res = 0;
|
|
|
|
res ^= g6.f0;
|
|
|
|
res ^= f6_load(&g6);
|
|
|
|
res ^= g6.f0;
|
|
|
|
return res;
|
2010-04-18 05:52:22 +08:00
|
|
|
}
|
2010-04-22 11:17:04 +08:00
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
// Check that we compute the best alignment possible for each access.
|
|
|
|
//
|
|
|
|
// CHECK-RECORD: *** Dumping IRgen Record Layout
|
2013-01-31 09:44:26 +08:00
|
|
|
// CHECK-RECORD: Record: RecordDecl{{.*}}s7
|
2010-04-22 11:17:04 +08:00
|
|
|
// CHECK-RECORD: Layout: <CGRecordLayout
|
Complete Rewrite of CGRecordLayoutBuilder
CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of
existing before ASTRecordLayoutBuilder. It redundantly performed many
layout operations that are now performed by ASTRecordLayoutBuilder and
asserted that the results were the same. With the addition of support
for the MS-ABI, such as placement of vbptrs, vtordisps, different
bitfield layout and a variety of other features, CGRecordLayoutBuilder
was growing unwieldy in its redundancy.
This patch re-architects CGRecordLayoutBuilder to not perform any
redundant layout but rather, as directly as possible, lower an
ASTRecordLayout to an llvm::type. The new architecture is significantly
smaller and simpler than the CGRecordLayoutBuilder and contains fewer
ABI-specific code paths. It's also one pass.
The architecture of the new system is described in the comments. For the
most part, the new system simply takes all of the fields and bases from
an ASTRecordLayout, sorts them, inserts padding and dumps a record.
Bitfields, unions and primary virtual bases make this process a bit more
complicated. See the inline comments.
In addition, this patch updates a few lit tests due to the fact that the
new system computes more accurate llvm types than CGRecordLayoutBuilder.
Each change is commented individually in the review.
Differential Revision: http://llvm-reviews.chandlerc.com/D2795
llvm-svn: 201907
2014-02-22 07:49:50 +08:00
|
|
|
// CHECK-RECORD: LLVMType:%struct.s7 = type { i32, i32, i32, i8, i32, [12 x i8] }
|
2010-08-23 05:01:12 +08:00
|
|
|
// CHECK-RECORD: IsZeroInitializable:1
|
2010-04-22 11:17:04 +08:00
|
|
|
// CHECK-RECORD: BitFields:[
|
Respect alignment of nested bitfields
tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test:
struct XBitfield {
unsigned b1 : 10;
unsigned b2 : 12;
unsigned b3 : 10;
};
struct YBitfield {
char x;
struct XBitfield y;
} __attribute((packed));
struct YBitfield gbitfield;
unsigned test7() {
// CHECK: @test7
// CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4
return gbitfield.y.b2;
}
The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single
i32 is of course possible, but that still doesn't make it 4-byte aligned as
it remains packed at offset 1 in the surrounding gbitfield object.
This alignment was changed by commit r169489, which also introduced changes
to bitfield access code in CGExpr.cpp. Code before that change used to take
into account *both* the alignment of the field to be accessed within the
current struct, *and* the alignment of that outer struct itself; this logic
was removed by the above commit.
Neglecting to consider both values can cause incorrect code to be generated
(I've seen an unaligned access crash on SystemZ due to this bug).
In order to always use the best known alignment value, this patch removes
the CGBitFieldInfo::StorageAlignment member and replaces it with a
StorageOffset member specifying the offset from the start of the surrounding
struct to the bitfield's underlying storage. This offset can then be combined
with the best-known alignment for a bitfield access lvalue to determine the
alignment to use when accessing the bitfield's storage.
Differential Revision: http://reviews.llvm.org/D11034
llvm-svn: 241916
2015-07-11 01:30:00 +08:00
|
|
|
// CHECK-RECORD: <CGBitFieldInfo Offset:0 Size:5 IsSigned:1 StorageSize:8 StorageOffset:12>
|
|
|
|
// CHECK-RECORD: <CGBitFieldInfo Offset:0 Size:29 IsSigned:1 StorageSize:32 StorageOffset:16>
|
2010-04-22 11:17:04 +08:00
|
|
|
|
|
|
|
struct __attribute__((aligned(16))) s7 {
|
|
|
|
int a, b, c;
|
|
|
|
int f0 : 5;
|
|
|
|
int f1 : 29;
|
|
|
|
};
|
|
|
|
|
|
|
|
int f7_load(struct s7 *a0) {
|
|
|
|
return a0->f0;
|
|
|
|
}
|
2010-04-22 22:56:10 +08:00
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
// This is a case where we narrow the access width immediately.
|
|
|
|
|
|
|
|
struct __attribute__((packed)) s8 {
|
|
|
|
char f0 : 4;
|
|
|
|
char f1;
|
|
|
|
int f2 : 4;
|
|
|
|
char f3 : 4;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct s8 g8 = { 0xF };
|
|
|
|
|
|
|
|
int f8_load(struct s8 *a0) {
|
|
|
|
return a0->f0 ^ a0 ->f2 ^ a0->f3;
|
|
|
|
}
|
|
|
|
int f8_store(struct s8 *a0) {
|
|
|
|
return (a0->f0 = 0xFD) ^ (a0->f2 = 0xFD) ^ (a0->f3 = 0xFD);
|
|
|
|
}
|
|
|
|
int f8_reload(struct s8 *a0) {
|
|
|
|
return (a0->f0 += 0xFD) ^ (a0->f2 += 0xFD) ^ (a0->f3 += 0xFD);
|
|
|
|
}
|
|
|
|
|
2013-08-15 14:47:53 +08:00
|
|
|
// CHECK-OPT-LABEL: define i32 @test_8()
|
2010-04-22 22:56:10 +08:00
|
|
|
// CHECK-OPT: ret i32 -3
|
|
|
|
// CHECK-OPT: }
|
|
|
|
unsigned test_8() {
|
|
|
|
struct s8 g8 = { 0xdeadbeef, 0xdeadbeef, 0xdeadbeef, 0xdeadbeef };
|
|
|
|
unsigned long long res = 0;
|
|
|
|
res ^= g8.f0 ^ g8.f2 ^ g8.f3;
|
|
|
|
res ^= f8_load(&g8) ^ f8_store(&g8) ^ f8_reload(&g8);
|
|
|
|
res ^= g8.f0 ^ g8.f2 ^ g8.f3;
|
|
|
|
return res;
|
|
|
|
}
|
2010-04-22 23:22:33 +08:00
|
|
|
|
|
|
|
/***/
|
|
|
|
|
|
|
|
// This is another case where we narrow the access width immediately.
|
|
|
|
//
|
|
|
|
// <rdar://problem/7893760>
|
|
|
|
|
|
|
|
struct __attribute__((packed)) s9 {
|
|
|
|
unsigned f0 : 7;
|
|
|
|
unsigned f1 : 7;
|
|
|
|
unsigned f2 : 7;
|
|
|
|
unsigned f3 : 7;
|
|
|
|
unsigned f4 : 7;
|
|
|
|
unsigned f5 : 7;
|
|
|
|
unsigned f6 : 7;
|
|
|
|
unsigned f7 : 7;
|
|
|
|
};
|
|
|
|
|
|
|
|
int f9_load(struct s9 *a0) {
|
|
|
|
return a0->f7;
|
|
|
|
}
|