| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 101221
|
|
|
|
| |
llvm-svn: 101215
|
|
|
|
|
|
|
|
|
|
|
|
| |
decomposition, instead of computing the access policy itself.
- This lets the method focus slightly more on emitting clean IR to honor the policy which has been selected. On 403.gcc's combine.c, x86_64, -O0, this reduces the number of lines in the .ll file (~= # of instructions) by 2.5%.
- No intended functionality change -- at -O3 this should produce equivalent if not identical output. On 403.gcc's combine.c, x86_64, -O3, this isn't quite true and some of the changes are regressions, but I'm not going to worry about that until we move to a new access policy.
- There is still some room for improvement in the generated IR, in particular we can usually fold the sign-extension of the bit-field into one of the component access. See the FIXME.
llvm-svn: 101192
|
|
|
|
|
|
|
|
|
|
| |
"policy" with which a bit-field should be accessed.
- For now, these policies are computed to match the current IRgen strategy, although the new information isn't being used yet (except in -fdump-record-layouts).
- Design comments appreciated.
llvm-svn: 101178
|
|
|
|
| |
llvm-svn: 101161
|
|
|
|
|
|
|
| |
property (atomic/nonatomic) is of aggregate type with
gc'able member objects) (NeXT runtime).
llvm-svn: 101156
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
elements with explicit zero values instead of with tail padding.
On an example like this:
struct foo { int a; int b; };
struct foo fooarray[] = {
{1, 2},
{4},
};
We now lay this out as:
@fooarray = global [2 x %struct.foo] [%struct.foo { i32 1, i32 2 }, %struct.foo { i32 4, i32 0 }]
instead of as:
@fooarray = global %0 <{ %struct.foo { i32 1, i32 2 }, %1 { i32 4, [4 x i8] zeroinitializer } }>
Preserving both the struct type of the second element, but also the array type of the entire thing.
llvm-svn: 101155
|
|
|
|
| |
llvm-svn: 101153
|
|
|
|
| |
llvm-svn: 101152
|
|
|
|
| |
llvm-svn: 101151
|
|
|
|
|
|
|
| |
atomicity of aggregate properties in setter/getter
methods. wip.
llvm-svn: 101107
|
|
|
|
| |
llvm-svn: 101100
|
|
|
|
|
|
|
|
| |
trailing fields may not be represented in initializer lists, they
are being handled as padding and those fields *must* be zero
initialized.
llvm-svn: 101067
|
|
|
|
| |
llvm-svn: 101066
|
|
|
|
| |
llvm-svn: 101052
|
|
|
|
|
|
| |
-fdump-record-layouts.
llvm-svn: 101051
|
|
|
|
|
|
| |
initializes a virtual base or not.
llvm-svn: 101004
|
|
|
|
|
|
| |
construction vtables in some cases.
llvm-svn: 100998
|
|
|
|
| |
llvm-svn: 100991
|
|
|
|
| |
llvm-svn: 100990
|
|
|
|
| |
llvm-svn: 100986
|
|
|
|
| |
llvm-svn: 100985
|
|
|
|
| |
llvm-svn: 100953
|
|
|
|
| |
llvm-svn: 100949
|
|
|
|
| |
llvm-svn: 100946
|
|
|
|
| |
llvm-svn: 100945
|
|
|
|
| |
llvm-svn: 100942
|
|
|
|
| |
llvm-svn: 100938
|
|
|
|
| |
llvm-svn: 100928
|
|
|
|
|
|
| |
unsafe.
llvm-svn: 100926
|
|
|
|
|
|
| |
serve as a source of source locations for the can't-yet-mangle diagnostic.
llvm-svn: 100924
|
|
|
|
| |
llvm-svn: 100919
|
|
|
|
| |
llvm-svn: 100918
|
|
|
|
| |
llvm-svn: 100909
|
|
|
|
|
|
|
| |
mangling an unknown expression kind. Also conveniently tells the user what
kind of expression they should add to the mangler!
llvm-svn: 100907
|
|
|
|
|
|
|
|
| |
just integer-literal expressions with special case implementations in the AST.
Fixes rdar://problem/7825453.
llvm-svn: 100905
|
|
|
|
| |
llvm-svn: 100778
|
|
|
|
| |
llvm-svn: 100776
|
|
|
|
| |
llvm-svn: 100775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__cxxabiv1::__fundamental_type_info in every translation
unit. Previously, we would perform name lookup for
__cxxabiv1::__fundamental_type_info at the end of IRGen for a each
translation unit, to determine whether it was present. If so, we we
produce type information for all of the fundamental types. However,
this name lookup causes PCH deserialization of a significant part of the
translation unit, which has a woeful impact on performance.
With this change, we now look at each record type after we've
generated its vtable to see if it is
__cxxabiv1::__fundamental_type_info. If so, we generate type info for
all of the fundamental types. This works because
__cxxabiv1::__fundamental_type_info should always have a key function
(typically the virtual destructor), that will be defined once in the
support library. The fundamental type information will end up there.
Fixes <rdar://problem/7840011>.
llvm-svn: 100772
|
|
|
|
|
|
| |
bit-field LValues to just store the base address of object containing the bit-field.
llvm-svn: 100745
|
|
|
|
|
|
|
|
| |
to the intrinsic, even when math-errno is off.
Fixes rdar://problem/7828230 by falling back on the library function.
llvm-svn: 100613
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
have the code generate slap a srcloc metadata on inline asm nodes.
This allows us to diagnose invalid inline asms with such nice
diagnostics as:
<inline asm>:1:2: error: unrecognized instruction
abc incl %eax
^
asm.c:2:12: note: generated from here
__asm__ ("abc incl %0" : "+r" (X));
^
2 diagnostics generated.
llvm-svn: 100608
|
|
|
|
| |
llvm-svn: 100534
|
|
|
|
| |
llvm-svn: 100513
|
|
|
|
| |
llvm-svn: 100512
|
|
|
|
| |
llvm-svn: 100511
|
|
|
|
|
|
|
|
|
| |
- Unfortunately, this requires some horrible code in CGObjCMac which always
allocats a CGBitFieldInfo because we don't currently build a proper layout
for Objective-C classes. It needs to be cleaned up, but I don't want the
bit-field cleanups to be blocked on that.
llvm-svn: 100474
|
|
|
|
| |
llvm-svn: 100462
|
|
|
|
| |
llvm-svn: 100433
|