| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 73702
|
|
|
|
|
|
|
|
|
|
| |
___Block_byref_id_object_dispose and ___Block_byref_id_object_copy
functions so that we can simply reuse instead of creating a new one.
Additionally, add an assert to ensure no one yet tries to align a
__block variable beyond the alignment of a pointer as the codegen is
incomplete.
llvm-svn: 72974
|
|
|
|
| |
llvm-svn: 72462
|
|
|
|
|
|
| |
appropriate debug descriptor as well in that case.
llvm-svn: 72261
|
|
|
|
| |
llvm-svn: 72118
|
|
|
|
|
|
| |
type, make them unsupported for now.
llvm-svn: 72034
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables. For this to work, the backend needs to handle more complex
forms for locations.
A typical utterance would be:
%forwarding = getelementptr %0* %use_by_ref, i32 0, i32 1 ; <i8**> [#uses=1]
%0 = load i8** %forwarding ; <i8*> [#uses=1]
%1 = bitcast i8* %0 to %0* ; <%0*> [#uses=1]
%x = getelementptr %0* %1, i32 0, i32 4 ; <i32*> [#uses=1]
%2 = bitcast i32* %x to { }* ; <{ }*> [#uses=1]
call void @llvm.dbg.declare({ }* %2, { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable to { }*))
Presently when selection finds something it doesn't understand, it
just avoids generating any information, which is safe, just
incomplete. Radar 6867696
llvm-svn: 71824
|
|
|
|
|
|
|
|
|
| |
to allow us to support generation of deferred ctors/dtors.
It looks like codegen isn't emitting a call to the dtor in
member-functions.cpp:test2, but when it does, its body should
get emitted.
llvm-svn: 71594
|
|
|
|
|
|
| |
make sure to bitcast the argument so it has the same type as the first argument of the cleanup function. Fixes <rdar://problem/6827047>.
llvm-svn: 70098
|
|
|
|
|
|
| |
subsequently crashed).
llvm-svn: 69567
|
|
|
|
| |
llvm-svn: 69545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Exposed quite a few Sema issues and a CodeGen crash.
- See FIXMEs in test case, and in SemaDecl.cpp (PR3983).
I'm skeptical that __private_extern__ should actually be a storage
class value. I think that __private_extern__ basically amounts to
extern A __attribute__((visibility("hidden")))
and would be better off handled (a) as that, or (b) with an extra bit
in the VarDecl.
llvm-svn: 69020
|
|
|
|
|
|
| |
- No functionality change.
llvm-svn: 68987
|
|
|
|
| |
llvm-svn: 68756
|
|
|
|
| |
llvm-svn: 68755
|
|
|
|
|
|
| |
when the destination has a reference type. (No functionality change yet)
llvm-svn: 68593
|
|
|
|
|
|
| |
values are never being used in the function.
llvm-svn: 68328
|
|
|
|
| |
llvm-svn: 68280
|
|
|
|
|
|
| |
declaration. Reject it.
llvm-svn: 68058
|
|
|
|
|
|
| |
build. This shaves another 3% off.
llvm-svn: 67460
|
|
|
|
|
|
|
|
|
| |
in release-assert builds. For automatic variables, explicitly set
a name with setName that does not make a temporary std::string.
This speeds up -emit-llvm-only -disable-free on PR3810 by 4.6%
llvm-svn: 67459
|
|
|
|
|
|
| |
copy_helpers and dispose_helpers as necessary for them.
llvm-svn: 67453
|
|
|
|
| |
llvm-svn: 67406
|
|
|
|
| |
llvm-svn: 66343
|
|
|
|
| |
llvm-svn: 66322
|
|
|
|
| |
llvm-svn: 66257
|
|
|
|
| |
llvm-svn: 66247
|
|
|
|
| |
llvm-svn: 66243
|
|
|
|
| |
llvm-svn: 66241
|
|
|
|
| |
llvm-svn: 66231
|
|
|
|
|
|
|
|
| |
- For one thing, this adds unneeded overhead; for another, this
routine can be used to emit unnamed decls which we shouldn't try to
mangle.
llvm-svn: 66212
|
|
|
|
| |
llvm-svn: 66159
|
|
|
|
| |
llvm-svn: 66126
|
|
|
|
|
|
| |
necessary.
llvm-svn: 66117
|
|
|
|
|
|
| |
booleans.
llvm-svn: 66012
|
|
|
|
| |
llvm-svn: 66010
|
|
|
|
|
|
|
| |
still give an unsupported error for them due to the fact this is a
work in progress.
llvm-svn: 66007
|
|
|
|
| |
llvm-svn: 65688
|
|
|
|
|
|
| |
- PR3662.
llvm-svn: 65472
|
|
|
|
|
|
| |
- No functionality change.
llvm-svn: 65470
|
|
|
|
|
|
|
|
| |
global variable) out of GenerateStaticBlockVarDecl.
- No intended functionality change.
- Prep for some mild cleanups and PR3662.
llvm-svn: 65466
|
|
|
|
|
|
|
| |
CodeGen. I'm not sure whether this actually makes any visible
difference, but it's better to be consistent anyway.
llvm-svn: 65259
|
|
|
|
| |
llvm-svn: 65089
|
|
|
|
| |
llvm-svn: 64984
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRgen no longer relies on isConstantInitializer, instead we just try
to emit the constant. If that fails then in C we emit an error
unsupported (this occurs when Sema accepted something that it doesn't
know how to fold, and IRgen doesn't know how to emit) and in C++ we
emit a guarded initializer.
This ends up handling a few more cases, because IRgen was actually
able to emit some of the constants Sema accepts but can't Evaluate().
For example, PR3398.
llvm-svn: 64780
|
|
|
|
| |
llvm-svn: 64502
|
|
|
|
|
|
| |
- PR3566
llvm-svn: 64492
|
|
|
|
| |
llvm-svn: 64445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ABI to the CodeGen library. Since C++ code-generation is so
incomplete, we can't exercise much of this mangling code. However, a
few smoke tests show that it's doing the same thing as GCC. When C++
codegen matures, we'll extend the ABI tester to verify name-mangling
as well, and complete the implementation here.
At this point, the major client of name mangling is in the uses of the
new "overloadable" attribute in C, which allows overloading. Any
"overloadable" function in C (or in an extern "C" block in C++) will
be mangled the same way that the corresponding C++ function would be
mangled.
llvm-svn: 64413
|
|
|
|
| |
llvm-svn: 64411
|