| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
|
|
|
|
|
| |
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
llvm-svn: 86430
|
|
|
|
|
|
| |
works. (The old code will still be there until we know that everything works well.
llvm-svn: 77190
|
|
|
|
|
|
|
|
| |
- This is just to normalize, these will go away soon hopefully.
Added all the missing '&&'s that have crept in. :)
llvm-svn: 77062
|
|
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|
|
|
|
|
|
| |
Otherwise, failing tests other than the last one will not be reported.
llvm-svn: 52231
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nothing fundamentally wrong with it. Emitting unpacked structs where
possible is more work for almost no practical benefit. We'll probably
want to fix it at some point anyway, but it's low priority.
The issue with long double in particular is that LLVM thinks an X86 long
double is 10 bytes, while clang considers it for all purposes to be
either 12 or 16 bytes, depending on the platform, even in a packed
struct.
llvm-svn: 51673
|
|
|
|
|
|
|
|
|
| |
level code in clang. This is a cleanup, but does implement "-o" for
-emit-llvm. One effect of this is that "clang foo.c -emit-llvm" will now
emit into foo.ll instead of stdout. Use "clang foo.c -emit-llvm -o -" or
"clang < foo.c -emit-llvm" to get the old behavior.
llvm-svn: 46791
|
|
|
|
| |
llvm-svn: 46230
|
|
|
|
|
|
| |
For example, struct { char a; short b:2; };
llvm-svn: 44830
|
|
|
|
|
|
|
| |
struct STestB1 {char a; char b:2; } stb1;
struct STestB2 {char a; char b:5; char c:4} stb2;
llvm-svn: 44664
|
|
|
|
| |
llvm-svn: 43590
|
|
llvm-svn: 43577
|