| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 134989
|
|
|
|
|
|
| |
and kill a lot of redundant code.
llvm-svn: 134988
|
|
|
|
|
|
| |
StructType::get() and TargetData::getIntPtrType().
llvm-svn: 134982
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
builds introduced in r134972:
lib/CodeGen/CGExpr.cpp:1294:7: error: no matching function for call to 'EmitBitCastOfLValueToProperType'
lib/CodeGen/CGExpr.cpp:1278:1: note: candidate function not viable: no known conversion from 'CGBuilderTy' (aka 'IRBuilder<false>') to 'llvm::IRBuilder<> &' for 1st argument
This fixes the issue by passing CodeGenFunction on down, and using its
builder directly rather than passing just the builder down.
This may not be the best / cleanest fix, Chris please review. It at
least fixes builds.
llvm-svn: 134977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncompleted struct types. We now do what llvm-gcc does and compile
them into [i8 x 0]. If the type is later completed, we make sure that
it is appropriately cast.
We compile the terrible example to something like this now:
%struct.A = type { i32, i32, i32 }
@g = external global [0 x i8]
define void @_Z1fv() nounwind {
entry:
call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*))
ret void
}
declare void @_Z3fooP1A(%struct.A*)
define %struct.A* @_Z2f2v() nounwind {
entry:
ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1)
}
llvm-svn: 134972
|
|
|
|
|
|
| |
fixes the -m32 build of oggenc.
llvm-svn: 134971
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
us to compile
stuff like this:
typedef struct {
int x, y, z;
} foo_t;
foo_t g;
into:
%"struct.<anonymous>" = type { i32, i32, i32 }
we now get:
%struct.foo_t = type { i32, i32, i32 }
This doesn't change the behavior of the compiler, but makes the IR much easier to read.
llvm-svn: 134969
|
|
|
|
| |
llvm-svn: 134966
|
|
|
|
|
|
| |
expectations in EmitCall. Next patch will take this further.
llvm-svn: 134962
|
|
|
|
| |
llvm-svn: 134952
|
|
|
|
|
|
| |
passing.
llvm-svn: 134951
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an assert on Darwin llvm-gcc builds.
Assertion failed: (castIsValid(op, S, Ty) && "Invalid cast!"), function Create, file /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.llvm-gcc-i386-darwin9-RA/llvm.src/lib/VMCore/Instructions.cpp, line 2067.
etc.
http://smooshlab.apple.com:8013/builders/llvm-gcc-i386-darwin9-RA/builds/2354
--- Reverse-merging r134888 into '.':
U lib/CodeGen/CodeGenModule.cpp
llvm-svn: 134950
|
|
|
|
|
|
| |
which is: { <4 x float>, <4 x float> } should continue to go through memory.
llvm-svn: 134946
|
|
|
|
|
|
| |
people write useful cleanup classes.
llvm-svn: 134942
|
|
|
|
|
|
| |
add one more testcase.
llvm-svn: 134934
|
|
|
|
| |
llvm-svn: 134913
|
|
|
|
| |
llvm-svn: 134893
|
|
|
|
|
|
|
|
|
|
|
| |
- an off-by-one error in emission of irregular array limits for
InitListExprs
- use an EH partial-destruction cleanup within the normal
array-destruction cleanup
- get the branch destinations right for the empty check
Also some refactoring which unfortunately obscures these changes.
llvm-svn: 134890
|
|
|
|
| |
llvm-svn: 134888
|
|
|
|
| |
llvm-svn: 134880
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is called whenever a tag type is completed. We previously used that
as the sign to layout the codegen representation for the tag type,
which worked but meant that we laid out *every* completed type, whether
it was used or not.
Now we just lay out the type if we've already seen it somehow else.
This means that we lay out types we've used but haven't seen a body
for, but we don't lay out tons of stuff that noone cares about.
llvm-svn: 134866
|
|
|
|
|
|
|
|
| |
adjustment, allowing
us to revert the other half of r134860. Now things are back to a relatively tidy state.
llvm-svn: 134865
|
|
|
|
| |
llvm-svn: 134864
|
|
|
|
|
|
|
|
|
|
| |
caused us to skip layout out a function accurately. If
so, flush the type cache for both the function and struct
case to ensure that any pointers to the functions get
recomputed. This is overconservative, but with this patch
clang can build itself again.
llvm-svn: 134863
|
|
|
|
|
|
|
| |
type, even when in the struct case. This was one root issue that was
causing type mismatches throughout the compiler.
llvm-svn: 134862
|
|
|
|
|
|
|
|
|
|
| |
conservative when converting a functiontype to IR when in a "pointer within
a struct" context. This has the unfortunate sideeffect of compiling all
function pointers inside of structs into "{}*" which, though correct, is
ugly. This has the positive side effect of being correct, and it is pretty
straight-forward to improve on this.
llvm-svn: 134861
|
|
|
|
|
|
|
| |
do an explicit bitcast to whatever ConvertType produces. This will
go with the next patch.
llvm-svn: 134860
|
|
|
|
| |
llvm-svn: 134855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it is a predicate, not an action. Change the return type to be a bool,
not the incomplete member. Enhace it to detect the recursive compilation
case, allowing us to compile Eli's testcase on llvmdev:
struct T {
struct T (*p)(void);
} t;
into:
%struct.T = type { {}* }
@t = common global %struct.T zeroinitializer, align 8
llvm-svn: 134853
|
|
|
|
|
|
|
| |
the enum has already been converted. If not, there cannot be any types
built on top of it, so there is no need to flush the cache.
llvm-svn: 134841
|
|
|
|
| |
llvm-svn: 134831
|
|
|
|
|
|
|
|
| |
expecting so much concentrated oddity on what seemed like a
trivial feature. Thanks to François Pichet for doing the
MSVC legwork here.
llvm-svn: 134813
|
|
|
|
| |
llvm-svn: 134785
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Emit default-initialization of arrays that were partially initialized
with initializer lists with a loop, rather than emitting the default
initializer N times;
- support destroying VLAs of non-trivial type, although this is not
yet exposed to users; and
- support the partial destruction of arrays initialized with
initializer lists when an initializer throws an exception.
llvm-svn: 134784
|
|
|
|
|
|
|
|
|
|
|
|
| |
should not imply -mno-sse.
Note that because we don't usually touch the MMX registers anyway, all -mno-mmx needs to do is tweak the x86-32 calling convention a little for vectors that look like MMX vectors, and prevent the definition of __MMX__.
clang doesn't actually stop the user from using MMX inline asm operands or MMX builtins in -mno-mmx mode; as a QOI issue, it would be nice to diagnose, but I doubt it really matters much.
<rdar://problem/9694837>
llvm-svn: 134770
|
|
|
|
| |
llvm-svn: 134765
|
|
|
|
| |
llvm-svn: 134761
|
|
|
|
| |
llvm-svn: 134754
|
|
|
|
| |
llvm-svn: 134743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the normal case.
Before, for this:
$ cat t.c
int test(int x) { return x * 2; }
We would get this:
addl %edi, %edi
jno LBB0_2
## BB#1: ## %overflow
ud2
LBB0_2: ## %nooverflow
movl %edi, %eax
popq %rbp
ret
Now we get this:
addl %edi, %edi
jo LBB0_2
## BB#1: ## %nooverflow
movl %edi, %eax
popq %rbp
ret
LBB0_2: ## %overflow
ud2
<rdar://problem/8283919>
llvm-svn: 134642
|
|
|
|
|
|
| |
so roll it out.
llvm-svn: 134638
|
|
|
|
|
|
| |
function. Fixes PR10233!
llvm-svn: 134634
|
|
|
|
|
|
| |
required to support the transitional ABI.
llvm-svn: 134612
|
|
|
|
|
|
| |
pure-nonfragile ABI for both ARC and GC mode.
llvm-svn: 134611
|
|
|
|
|
|
|
|
|
|
|
|
| |
where we have an immediate need of a retained value.
As an exception, don't do this when the call is made as the immediate
operand of a __bridge retain. This is more in the way of a workaround
than an actual guarantee, so it's acceptable to be brittle here.
rdar://problem/9504800
llvm-svn: 134605
|
|
|
|
| |
llvm-svn: 134589
|
|
|
|
| |
llvm-svn: 134536
|
|
|
|
|
|
|
| |
exception in Objective-C; in Objective-C++ we still use std::terminate().
This is only available in very recent runtimes.
llvm-svn: 134456
|
|
|
|
|
|
|
|
|
|
|
|
| |
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
|
|
|
|
|
|
| |
hardwired into the default pass list.
llvm-svn: 134445
|