llvm-svn: 159091

This adds support for the tls_model attribute. This allows the user to
choose a TLS model that is better than what LLVM would select by
default. For example, a variable might be declared as:

  __thread int x __attribute__((tls_model("initial-exec")));

if it will not be used in a shared library that is dlopen'ed.

This depends on LLVM r159077.

llvm-svn: 159078

target Objective-C runtime down to the frontend:  break this
down into a single target runtime kind and version, and compute
all the relevant information from that.  This makes it
relatively painless to add support for new runtimes to the
compiler.  Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime.  This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.

As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.

I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.

llvm-svn: 158793

__forceinline is a combination of the inline keyword and __attribute__((always_inline))

llvm-svn: 158653

initialization, and use that information to produce the right kind of
initialization during template instantiation.

llvm-svn: 158288

In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.

This rolls back r155808 and r155869.

Review by Doug Gregor incorporating feedback from Chandler Carruth.

llvm-svn: 158104

llvm-svn: 157557

Because in CUDA types do not have associated address spaces,
globals are declared in their "native" address space, and accessed
by bitcasting the pointer to address space 0.  This relies on address
space 0 being a unified address space.

llvm-svn: 157167

Currently cold functions are marked with the "optsize" attribute in CodeGen
so they are always optimized for size.  The hot attribute is just ignored,
LLVM doesn't have a way to express hotness at the moment.

llvm-svn: 156723

It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.

Reviewed by Eric Christopher.

llvm-svn: 156160

filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.

This change errs on the side of value, making op-> return T* and op* return
T&.

(reviewed by Richard Smith)

llvm-svn: 155808

llvm-svn: 155697

llvm-svn: 155430

llvm-svn: 154880

an explicit instance variable.

rdar://10590352

llvm-svn: 154481

These patches cause us to miscompile and/or reject code with static
function-local variables in an extern-C context. Previously, we were
papering over this as long as the variables are within the same
translation unit, and had not seen any failures in the wild. We still
need a proper fix, which involves mangling static locals inside of an
extern-C block (as GCC already does), but this patch causes pretty
widespread regressions. Firefox, and many other applications no longer
build.

Lots of test cases have been posted to the list in response to this
commit, so there should be no problem reproducing the issues.

llvm-svn: 153768

other things which might mess with the variable's type.

llvm-svn: 153733

section. A 'normal' string will go into the __TEXT,__const section, but this
isn't good for UTF16 strings. The __ustring section allows for coalescing, among
other niceties (such as allowing the linker to easily split up strings).

Instead of outputting the UTF16 string as a series of bytes, output it as a
series of shorts. The back-end will then nicely place the UTF16 string into the
correct section, because it's a mensch.
<rdar://problem/10655949>

llvm-svn: 153710

llvm-svn: 153698

llvm-svn: 153447

llvm-svn: 153389

The member variable is always "LangOpts" and the member function is always "getLangOpts".

Reviewed by Chris Lattner

llvm-svn: 152536

HandleCXXStaticMemberVarInstantiation. Suggested by Argyrios.

llvm-svn: 152320

In the included testcase, soma thinks that we already have a definition after we
see the out of line decl. Codegen puts it in a deferred list, to be output if
a use is seen. This would break when we saw an explicit template instantiation
definition, since codegen would not be notified.

This patch adds a method to the consumer interface so that soma can notify
codegen that this decl is now required.

llvm-svn: 152024

scalar emission of DeclRefExprs to const bools: emit scalar bools as i1,
not as i8.

In addition to the extra unit testing, this has successfully bootstrapped.

llvm-svn: 151955

llvm-svn: 151586

This emits a backing array with internal linkage and fills it with data,
then has the initializer_list point at the array. Dynamic initialization
and global destructors are correctly supported.

What doesn't work is nested initializer_lists. I have no idea how to
get them to work, either. However, these should be very rare, and so
I'll just call it a known bug and declare generalized initializers
DONE!

llvm-svn: 151457

emit less than complete types on purpose on occasion and so
our caches aren't useful for this kind of lazy emitting.

llvm-svn: 150856

as constants.

Refactor and simplify all the separate checks for whether a type can be
emitted as a constant.

llvm-svn: 150793

 1) It has a const-qualified type, and
 2) It has no mutable members, and
 3) It has no dynamic initialization, and
 4) It has trivial destruction.
Remove the unnecessary requirement that the type be POD. This allows us to
mark all constexpr objects with no mutable members as 'constant'.

llvm-svn: 150792

optional argument passed through the variadic ellipsis)
potentially affects how we need to lower it.  Propagate
this information down to the various getFunctionInfo(...)
overloads on CodeGenTypes.  Furthermore, rename those
overloads to clarify their distinct purposes, and make
sure we're calling the right one in the right place.
This has a nice side-effect of making it easier to construct
a function type, since the 'variadic' bit is no longer
separable.

This shouldn't really change anything for our existing
platforms, with one minor exception --- we should now call
variadic ObjC methods with the ... in the "right place"
(see the test case), which I guess matters for anyone
running GNUStep on MIPS.  Mostly it's just a substantial
clean-up.

llvm-svn: 150788

-fno-objc-arc-exceptions. This will allow the optimizer to perform
optimizations which are only safe under that flag.

This is a part of rdar://10803830.

llvm-svn: 150644

constructor, and that constructor is used to initialize an object of static
storage duration such that all members and bases are initialized by constant
expressions, constant initialization is performed. In this case, the object
can still have a non-trivial destructor, and if it does, we must emit a dynamic
initializer which performs no initialization and instead simply registers that
destructor.

llvm-svn: 150419

llvm-svn: 149943

llvm-svn: 149928

allocating an std::string.

llvm-svn: 149924

llvm-svn: 149916

llvm-svn: 149801

(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)

llvm-svn: 149799

attribute into CodeGenModule::SetLLVMFunctionAttributesForDefinition().

Previously it resided in CodeGenModule::GetOrCreateLLVMFunction, which
for some reason wasn't called for ObjC class methods, see
http://code.google.com/p/address-sanitizer/issues/detail?id=33

llvm-svn: 149605