| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
just to save the current insertion state! This change significantly
simplifies the IR CFG in exceptions code.
llvm-svn: 101996
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. The ObjCMessageExpr node represents four different kinds of
message sends in a single AST node:
1) Send to a object instance described by an expression (e.g., [x method:5])
2) Send to a class described by the class name (e.g., [NSString method:5])
3) Send to a superclass class (e.g, [super method:5] in class method)
4) Send to a superclass instance (e.g., [super method:5] in instance method)
Previously these four cases where tangled together. Now, they have
more distinct representations. Specific changes:
1) Unchanged; the object instance is represented by an Expr*.
2) Previously stored the ObjCInterfaceDecl* referring to the class
receiving the message. Now stores a TypeSourceInfo* so that we know
how the class was spelled. This both maintains typedef information
and opens the door for more complicated C++ types (e.g., dependent
types). There was an alternative, unused representation of these
sends by naming the class via an IdentifierInfo *. In practice, we
either had an ObjCInterfaceDecl *, from which we would get the
IdentifierInfo *, or we fell into the case below...
3) Previously represented by a class message whose IdentifierInfo *
referred to "super". Sema and CodeGen would use isStr("super") to
determine if they had a send to super. Now represented as a
"class super" send, where we have both the location of the "super"
keyword and the ObjCInterfaceDecl* of the superclass we're
targetting (statically).
4) Previously represented by an instance message whose receiver is a
an ObjCSuperExpr, which Sema and CodeGen would check for via
isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
where we have both the location of the "super" keyword and the
ObjCInterfaceDecl* of the superclass we're targetting
(statically). Note that ObjCSuperExpr only has one remaining use in
the AST, which is for "super.prop" references.
The new representation of ObjCMessageExpr is 2 pointers smaller than
the old one, since it combines more storage. It also eliminates a leak
when we loaded message-send expressions from a precompiled header. The
representation also feels much cleaner to me; comments welcome!
This patch attempts to maintain the same semantics we previously had
with Objective-C message sends. In several places, there are massive
changes that boil down to simply replacing a nested-if structure such
as:
if (message has a receiver expression) {
// instance message
if (isa<ObjCSuperExpr>(...)) {
// send to super
} else {
// send to an object
}
} else {
// class message
if (name->isStr("super")) {
// class send to super
} else {
// send to class
}
}
with a switch
switch (E->getReceiverKind()) {
case ObjCMessageExpr::SuperInstance: ...
case ObjCMessageExpr::Instance: ...
case ObjCMessageExpr::SuperClass: ...
case ObjCMessageExpr::Class:...
}
There are quite a few places (particularly in the checkers) where
send-to-super is effectively ignored. I've placed FIXMEs in most of
them, and attempted to address send-to-super in a reasonable way. This
could use some review.
llvm-svn: 101972
|
|
|
|
|
|
|
| |
It is ok to have c++-ness inside extern "C"
block. Fixes pr6644.
llvm-svn: 101948
|
|
|
|
| |
llvm-svn: 101921
|
|
|
|
|
|
|
| |
matches how we currently handle structs, and this correctly handles
-fno-bitfield-type-align.
llvm-svn: 101918
|
|
|
|
|
|
| |
we initialize the vtable pointer for a virtual base, and there was another path from the most derived class to another base with the same class type, we would use the wrong base.
llvm-svn: 101911
|
|
|
|
|
|
| |
function.
llvm-svn: 101909
|
|
|
|
|
|
|
|
|
| |
This mirror's Dan's patch for llvm-gcc in r97989, and
fixes the miscompilation in PR6525. There is some contention
over whether this is the right thing to do, but it is the
conservative answer and demonstrably fixes a miscompilation.
llvm-svn: 101877
|
|
|
|
|
|
| |
functionality change right now.
llvm-svn: 101872
|
|
|
|
|
|
| |
CodeGenFunction::GetAddressOfBaseClass is not ambiguous.
llvm-svn: 101869
|
|
|
|
|
|
|
|
| |
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
llvm-svn: 101826
|
|
|
|
|
|
| |
-fdump-record-layouts.
llvm-svn: 101815
|
|
|
|
|
|
| |
dumping.
llvm-svn: 101814
|
|
|
|
|
|
| |
(related to radar 7866951).
llvm-svn: 101799
|
|
|
|
|
|
| |
(related to PR6769).
llvm-svn: 101794
|
|
|
|
|
|
|
| |
in for pre-snowleoprd (NeXt runtime). Fixes
radar 7866951
llvm-svn: 101791
|
|
|
|
| |
llvm-svn: 101787
|
|
|
|
| |
llvm-svn: 101786
|
|
|
|
| |
llvm-svn: 101759
|
|
|
|
|
|
| |
runtime)
llvm-svn: 101758
|
|
|
|
|
|
|
|
| |
the method as available_externally.
Fixes PR6747
llvm-svn: 101757
|
|
|
|
|
|
|
| |
as they are accessible in static methods in a class
local to the same function. Fixes PR6769.
llvm-svn: 101756
|
|
|
|
|
|
| |
as a side-effect, remove two FIXMEs now fixed
llvm-svn: 101726
|
|
|
|
|
|
| |
where assigning to a bit-field member would overwrite other parts of the struct.
llvm-svn: 101681
|
|
|
|
| |
llvm-svn: 101678
|
|
|
|
|
|
| |
affect alignment.
llvm-svn: 101673
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 101671
|
|
|
|
| |
llvm-svn: 101666
|
|
|
|
| |
llvm-svn: 101660
|
|
|
|
|
|
| |
unused.
llvm-svn: 101643
|
|
|
|
|
|
|
|
| |
users of getNameAsString on a stream.
The next step is to print the name directly into the stream, avoiding a temporary std::string copy.
llvm-svn: 101632
|
|
|
|
|
|
|
|
|
|
| |
void exit_picture()
{
char yuv_types[4][6]= {"4:0:0","4:2:0","4:2:2","4:4:4"};
foo(yuv_types);
}
llvm-svn: 101623
|
|
|
|
| |
llvm-svn: 101568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct may cause it to shrink more than one byte. Before
my recent changes we compiled the new test into:
%0 = type { [6 x i8] }
@x = global %0 { [6 x i8] undef }, align 2 ; <%0*> [#uses=0]
which is obviously bogus. Now we compile it into:
%0 = type <{ i32, i8, i8 }>
@x = global %0 zeroinitializer, align 2 ; <%0*> [#uses=0]
Where the last byte only is tail padding.
llvm-svn: 101536
|
|
|
|
|
|
| |
merge also a few tests I had here for this feature, and FileCheck'ize one file
llvm-svn: 101535
|
|
|
|
|
|
| |
shortly (Daniel, please review).
llvm-svn: 101472
|
|
|
|
| |
llvm-svn: 101447
|
|
|
|
|
|
|
|
| |
arguments, it is now an immutable object.
Also, add some checking of various invariants that should hold on the CGBitFieldInfo access.
llvm-svn: 101345
|
|
|
|
| |
llvm-svn: 101344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Stop multiplying constant by 8 accordingly in the header and change
intrinsic definition for what types we expect.
Add to existing palignr test to check that we're emitting the correct things.
llvm-svn: 101332
|
|
|
|
|
|
| |
IRgen record layout, which this code doesn't need to depend on.
llvm-svn: 101257
|
|
|
|
|
|
| |
CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.", I think it might be breaking bootstrap.
llvm-svn: 101235
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 101222
|
|
|
|
| |
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
|