- Returns addr of constant for argument + '\0'.
- I couldn't think of a better name.
- Move appropriate users of GetAddrOfConstantString to this.
Rename getStringForStringLiteral to GetStringForStringLiteral.
Add GetAddrOfConstantStringFromLiteral
- This combines GetAddrOfConstantString and
GetStringForStringLiteral. This method can be, but is not yet, more
efficient.
Change GetAddrOfConstantString to not add terminating '\0'
- <rdar://problem/6140956>
llvm-svn: 54768
ObjCProtocolDecl directly.
Implement CodeGen support for forward protocol decls (no-ops are so
nice to implement).
Also moved CGObjCRuntime.h out of CodeGenModule.h
llvm-svn: 54709
Changed CGObjCRuntime::GenerateConstantString interface to take
std::string instead of char* and size.
Change ObjC functions which call on GenerateConstantString to bitcast
result to appropriate type.
llvm-svn: 54659
- Maps to LangOptions.Exceptions
- Currently always off, should autoselect based on language.
Update CodeGen to set unwind attribute on functions definitions based
on LangOptions.Exceptions.
- Still need to set attributes appropriately on calls.
llvm-svn: 54643
- Kill unnecessary #includes in .cpp files. This is an automatic
sweep so some things removed are actually used, but happen to be
included by a previous header. I tried to get rid of the obvious
examples and this was the easiest way to trim the #includes in one
fell swoop.
- We now return to regularly scheduled development.
llvm-svn: 54632
- Drop {Decl.h,DeclObjC.h,IdentifierTable.h} from Expr.h
- Moved Sema::getCurMethodDecl() out of line (dependent on
ObjCMethodDecl via dyn_cast).
llvm-svn: 54629
temporarily, I assumed GetAddrForConstantString literal was being
used consistently but it doesn't look like it is.
Factored out a CodeGenModule::getStringForStringLiteral which handles
extracting a std::string for the bytes of a StringLiteral, padded to
match the type.
Update EmitLValue to use getStringForStringLiteral, this was
previously not padding strings correctly. Good thing we only emit
strings in 4 different places!
llvm-svn: 54621
type.
- This generates somewhat less optimal code than before but this is
not hard to rectify once stable (at the cost of slightly more
complex code).
- This currently always uses little-endian ordering of the bitfield.
- This breaks the CodeGen/bitfield.c test because it was grepping for
hard-coded assembly instructions. Will fix once a better test case
is constructed (hard to do without execution).
- This fixes SingleSource/UnitTests/2006-01-23-InitializedBitField.c
and Regression/C/PR1386.c from the test suite.
- <rdar://problem/6085090>, <rdar://problem/6094169>
llvm-svn: 54395
- Changed EmitSub to work on all cases (arithmetic, ptr - int, ptr -
ptr) so that implementation matches that of other operators.
- Modify EmitCompoundAssign to compute and perform the appropriate
casts of left, right, and result types for the assorted pointer
arithmetic cases.
- Fix EmitSub (ptr - int) case to negate the rhs *after*
extension. This is critical when the rhs is unsigned (and needs
extension).
- This fixes cfrac.
- <rdr://6115726>
llvm-svn: 54392
scimark2 on Darwin.
- Added Sema support for asm-label on variables, which I forgot before.
- Update CodeGen to use GlobalDeclMap to determine if static Decls
require emission (instead of LLVM module name lookup). Important
since the Decl name and the LLVM module name can differ.
- <rdar://problem/6116729>
llvm-svn: 54388
having multiple bindings from all the possible decls which
conceptually map to the same global).
- This eliminates CodeGen depending on the LLVM module for name
lookup.
- This also eliminates the need for ReplaceMapValuesWith (hurrah).
- This handles lookups for FunctionDecls correctly in the presence of
aliases, this was previously broken.
- WIP: Can still clean up & unify variable and function emission.
llvm-svn: 54382
- Follows emission scheme used by llvm-gcc, i.e. invent an id for
each label whose address is taken and replace each indirect goto by
a switch to each possible target.
- Currently we emit a switch for each indirect goto instead of
merging them as llvm-gcc does.
llvm-svn: 54318
move getAsArrayType into ASTContext instead of being a method on type.
This is required because getAsArrayType(const AT), where AT is a typedef
for "int[10]" needs to return ArrayType(const int, 10).
Fixing this greatly simplifies getArrayDecayedType, which is a good sign.
llvm-svn: 54317
- There is an miscompilation issue remaining due to a poor
interaction between the delayed emission of static functions and
the emission of constructors, but that already existed prior to
this change.
llvm-svn: 54258
instead of mapping the decl to a bitcast of the global to the correct
type.
- GetAddrOf{Function,GlobalVar} introduce the bitcast on every use now.
- This solves a problem where a dangling pointer could be introduced
by the RAUW done when replacing a forward or tentative
definition. See testcase for more details.
- Fixes <rdar://problem/6108358>
llvm-svn: 54211
- No (intended) functionality change.
- Primary purpose is to clearly separate (lazy) construction of
globals that are a forward declaration or tentative definition from
those that are the final definition.
- Lazy construction is now encapsulated in
GetAddrOf{Function,GlobalVar} while final definitions are
constructed in EmitGlobal{Function,Var}Definition.
- External interface for dealing with globals is now limited to
EmitGlobal and GetAddrOf{Function,GlobalVar}.
- Also updated helper functions dealing with statics, annotations,
and ctors to be private.
llvm-svn: 54179
- Fix multiple issues with the way case ranges were emitted, see test
cases details about the specific issues.
- The root issue was not being careful about how basic blocks were
emitted which led to them being chained together incorrectly,
resulting in improper control flow.
- Fixes <rdar://problem/6098585>
llvm-svn: 54006
- Also cleaned up emission slightly
- Inspection of the code revealed several other bugs, however. Case
ranges are not properly wired and can result in switch cases being
dropped or even infinite loops. See: <rdar://problem/6098585>
Completes: <rdar://problem/6094119>
llvm-svn: 53975
1) add a new ASTContext::getFloatTypeSemantics method.
2) Use it from SemaExpr.cpp, CodeGenTypes.cpp and other places.
3) Change the TargetInfo.h get*Format methods to return their
fltSemantics byref instead of by pointer.
4) Change CodeGenFunction::EmitBuiltinExpr to allow builtins which
sometimes expand specially and othertimes fall back to libm.
5) Add support for __builtin_nan("") to codegen, cases that don't pass
in an empty string are currently lowered to libm calls.
6) Fix codegen of __builtin_infl.
llvm-svn: 52914
clang as a Release build.
The big change is that all AST nodes (subclasses of Stmt) whose children are
Expr* store their children as Stmt* or arrays of Stmt*. This is to remove
strict-aliasing warnings when using StmtIterator. None of the interfaces of any
of the classes have changed (except those with arg_iterators, see below), as the
accessor methods introduce the needed casts (via cast<>). While this extra
casting may seem cumbersome, it actually adds some important sanity checks
throughout the codebase, as clients using StmtIterator can potentially overwrite
children that are expected to be Expr* with Stmt* (that aren't Expr*). The casts
provide extra sanity checks that are operational in debug builds to catch
invariant violations such as these.
For classes that have arg_iterators (e.g., CallExpr), the definition of
arg_iterator has been replaced. Instead of it being Expr**, it is an actual
class (called ExprIterator) that wraps a Stmt**, and provides the necessary
operators for iteration. The nice thing about this class is that it also uses
cast<> to type-checking, which introduces extra sanity checks throughout the
codebase that are useful for debugging.
A few of the CodeGen functions that use arg_iterator (especially from
OverloadExpr) have been modified to take begin and end iterators instead of a
base Expr** and the number of arguments. This matches more with the abstraction
of iteration. This still needs to be cleaned up a little bit, as clients expect
that ExprIterator is a RandomAccessIterator (which we may or may not wish to
allow for efficiency of representation).
This is a fairly large patch. It passes the tests (except CodeGen/bitfield.c,
which was already broken) on both a Debug and Release build, but it should
obviously be reviewed.
llvm-svn: 52378
qualifier in the lvalue, and changes lvalue loads/stores to honor
the volatile flag. Places which need some further attention are marked
with FIXMEs.
Patch by Cédric Venet.
llvm-svn: 52264
reported on cfe-dev by Cédric Venet.
Note that I seriously doubt that this perticular construct is useful,
though: it's a pointer in an alternate address space pointing into
unqualified address space.
llvm-svn: 52076
much closer to passing the gcc struct layout tests.
It might be possible to refactor this a bit, but I'm not sure there's
actually enough common code for that to be useful.
To get the calling convention completely correct, a bit of
platform-specific code is necessary even for x86-Linux. On x86-Linux, the
alignment of function parameters is extremely strange; as far as I can tell,
it's always 4 except for SSE vectors or structs containing SSE vectors. I'm
continuing to investigate this.
llvm-svn: 51839
this does is reconstruct the type for structs and arrays if the type
wouldn't be compatible otherwise.
The assertion about packing in the struct type reconstruction code
sucks, but I don't see any obvious way to fix it. Maybe we need a general
utility method to take a list of types and alignments and try to construct an
unpacked type if possible?
llvm-svn: 51785
associated declaration. This is a prerequisite to handling
general union initializations; for example, an array of unions involving
pointers has to be turned into a struct because the elements can have
incompatible types.
I refactored the code a bit to make it more readable; now, the logic for
definitions is all in EmitGlobalVarInit.
The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it
separately.
By itself, this patch should not cause any visible changes.
llvm-svn: 51783
bit-field initialization; ugly code, X86-only, but it works, at least
for basic stuff. Separates/adds union initialization; currently disabled,
though, because the struct/array code needs modifications to support
elements of the wrong type.
Fixes PR2381 and PR2309 with the bit-field initialization. And NetHack
compiles and appears to work with a few tweaks (to work around the lack
of transparent_union support, and clang being a bit strict about
conflicting declarations).
llvm-svn: 51763
emit incomplete types, because they crash llc, and always use the
logical location as the current location so we don't crash doing invalid
queries on CurLoc.
llvm-svn: 51675
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
a few bugs, but I don't know of any in particular. This has good effects
besides cleanup, though: it also should make it easier to implement the
aligned and packed attributes, and also target-specific struct layouts,
because the code won't have to be duplicated in codegen.
llvm-svn: 51576
required for correctness in cases of copying a struct to itself or to
an overlapping struct (itself for cases like *a = *a, and overlapping
is possible with unions).
Hopefully, this won't end up being a perf issue; LLVM *should* be able
to optimize memmove to memcpy in a lot of cases, and for small copies
the generated code *should* be mostly comparable. (In reality, LLVM
is currently horrible at optimizing memmove, but that's a bug, not a
fundamental issue.)
gcc currently generates wrong code; that's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667.
llvm-svn: 51566
llvm::Type::isSingleValueType. Currently these two functions have
the same behavior, but soon isFirstClassType will return true for
struct and array types.
Clang may some day want to use of isFirstClassType for some of
these some day as an optimization, but it'll require some
consideration.
llvm-svn: 51446
actually work (instead of crashing llc), and there's enough info emitted
to get line number information in gdb. This should hopefully be helpful
for debugging non-working programs.
I got rid of the begin/endregion calls because the implementation wasn't
working; someone who knows the debugging info a bit better might try to
add it. I really have no clue how a compiler is supposed to emit them.
This commit shouldn't have any effect without -g.
llvm-svn: 51404
lib/CodeGen/CGExpr.cpp and to change include/clang/AST/Attr.h to
use its own enum for visibility types instead of using
llvm::GlobalValue::VisibilityTypes. These changes eliminate
dependencies in the AST library on LLVM's VMCore library.
llvm-svn: 51398
as far as I can tell, and it fixes code like test/CodeGen/functions.c.
(Whatever performance effect it might have, crashing on a
construct like this isn't really acceptable; I've run into this
multiple times.)
llvm-svn: 51312
implement bitfield codegen (although I don't envy the person who
implements it). This also prevents a crash on code like that from PR2309
(it's still broken, but it fails more gracefully).
llvm-svn: 51285
they were causing bad code to be emitted. There are two fixes here: one
makes sure we emit a string that is long enough, and one makes sure we
properly handle string initialization in init lists.
llvm-svn: 51259
used for _Bool is not the same as the primitive width (which for _Bool
is 1 bit). The load and store changes add some casts to make the
types consistent. The EmitLValue changes make sure that the pointer is
of an appropriate type for loading the bitfield.
This isn't perfect, but it's an improvement, and getting everything
right depends on actually laying out structs in an ABI-compliant way.
llvm-svn: 51224
expressing the full flexibility of the LLVM shufflevector instruction.
The expected immediate usage is in *mmintrin.h, so that they don't
depend on the mess of gcc-inherited (and not completely implemented)
shuffle builtins.
llvm-svn: 51113
vector of the same element type and half the width, with the high, low, even,
and odd elements respectively.
Allow member references to member references, so that .hi.hi gives you the high
quarter of a vector. This is fairly convenient syntax for some insert/extract
operations.
Remove some unnecessary methods/types in the ExtVectorElementExpr class.
llvm-svn: 50892
This is a fairly mechanical/large change. As a result, I avoided making any changes/simplifications that weren't directly related. I did break two Analysis tests. I also have a couple FIXME's in UninitializedValues.cpp. Ted, can you take a look? If the bug isn't obvious, I am happy to dig in and fix it (since I broke it).
llvm-svn: 49748
in CGObjCGNU.cpp and once in CGObjCEtoile.cpp. Moved its definition to
CGObjC.cpp. This resolves a build error in Xcode, and also cleans things up.
llvm-svn: 49429
remaining open issues I've communicated to him:
1) self can be assigned to, and his patch didn't handle it correctly.
2) CollectObjCIvarTypes is N^2 (because each subclass reprocesses
all parent class ivars) and flattens classes. If A derives from B,
and both have an int, I'd expect to get { {i32}, i32}, not { i32, i32}.
David, please review.
llvm-svn: 48970
lib dir and move all the libraries into it. This follows the main
llvm tree, and allows the libraries to be built in parallel. The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in. This speeds
up parallel builds, particularly incremental ones.
llvm-svn: 48402
Daniel Dunbar