without defining them.  This should be an error, but I'm paranoid about
"uses" that end up not actually requiring a definition.  I'll revisit later.

Also, teach IR generation to not set internal linkage on variable
declarations, just for safety's sake.  Doing so produces an invalid module
if the variable is not ultimately defined.

Also, fix several places in the test suite where we were using internal
functions without definitions.

llvm-svn: 126016

  - Have CGM precompute a number of commonly-used types
  - Have CGF copy that during initialization instead of recomputing them
  - Use TBAA info when initializing a parameter variable
  - Refactor the scalar ++/-- code

llvm-svn: 125562

llvm-svn: 125321

and we later find the definition, make sure that we add the definition
(not the declaration) to the list of deferred definitions to
emit. Fixes PR8864.

Thanks to Nick Lewycky for testing this	patch out

llvm-svn: 125157

Block{Function,Module} base class.  Minor other refactorings.

Fixed a few address-space bugs while I was there.

llvm-svn: 125085

We now emit everything except unused implicit virtual member functions when building the vtable.

llvm-svn: 124935

llvm-svn: 124837

llvm-svn: 124835

abi.

llvm-svn: 124834

This reopens PR99114, but that one at least can be avoided with an #include.
PR9130 cannot.

llvm-svn: 124780

is not defined in the current translation unit. Doing so lead to compile errors
such as PR9114.

Instead, when CodeGen is building the vtable, don't try to emit a definition
for functions that aren't marked used in the current translation unit.
Fixes PR9114.

llvm-svn: 124768

llvm-svn: 124651

* llvm-link would complains about mismatched visibility
* If we produce a relocation with an available_externally, it is good to know that
it is hidden.

llvm-svn: 124633

current translation unit as available_externally. 

This helps devirtualize the second example in PR3100, comment 18:

struct S { S() {}; virtual void xyzzy(); };
inline void foo(S *s) { s->xyzzy(); }
void bar() { S s; foo(&s); }

This involved four major changes:

1. In DefineUsedVTables, always mark virtual member functions as referenced for
   non-template classes and class template specializations.
2. In CodeGenVTables::ShouldEmitVTableInThisTU return true if optimizations are
   enabled, even if the key function is not implemented in this translation 
   unit. We don't ever do this for code compiled with -fapple-kext, because we
   don't ever want to devirtualize virtual member function calls in that case.
3. Give the correct linkage for vtables where the key function is not defined.
4. Update the linkage for RTTI structures when necessary.

llvm-svn: 124565

llvm-svn: 124550

Set the visibility for typeinfo names.

llvm-svn: 124548

Change CodeGenModule::setTypeVisibility to take a TypeVisibilityKind enum instead of an "IsForRTTI" flag.

llvm-svn: 124546

llvm-svn: 124542

llvm-svn: 124541

llvm-svn: 124538

Add a new function, to be used by CGRTTI, CGVTables and CGVTT (which each has their own copy of this code).

llvm-svn: 124537

llvm-svn: 124536

llvm-svn: 124529

Mark VTables and RTTI data linkonce_odr instead of weak_odr, with the exception of explicit template instantiations, which have to be weak_odr.

This fixes PR6996.

llvm-svn: 124089

llvm-svn: 124029

llvm-svn: 123773

ASTContext::toCharUnitsFromBits() when converting from bit sizes to char units.

llvm-svn: 123720

llvm-svn: 123681

const NSConstantString *appKey =  @"MyApp";

llvm-svn: 123680

__builtin___CFStringMakeConstantString
This fixes PR8993. A darwin expert might want to check that this is safe.

llvm-svn: 123658

process, perform a number of refactorings:

- Move MiscNameMangler member functions to MangleContext
- Remove GlobalDecl dependency from MangleContext
- Make MangleContext abstract and move Itanium/Microsoft functionality
  to their own classes/files
- Implement ASTContext::createMangleContext and have CodeGen use it

No (intended) functionality change.

llvm-svn: 123386

think it is safe to mark all type infos with unnamed_addr, but I am not sure.

llvm-svn: 123275

llvm-svn: 123197

static const char foo[] = "foo";
static const char *bar = "bar";

the global created to hold "bar" will have it, but foo will not.

llvm-svn: 123192

llvm-svn: 122634

within the class.  Teach IR gen to look for function definitions in record
lexical contexts when deciding whether to emit a function whose address    
was taken.  Fixes PR8789.

llvm-svn: 121833

rdar://8560647

llvm-svn: 120650

data members by delaying the emission of the initializer until after
linkage and visibility have been set on the global.  Also, don't
emit a guard unless the variable actually ends up with vague linkage,
and don't use thread-safe statics in any case.

llvm-svn: 118336

visibility of their function.

llvm-svn: 118065

independently of whether they're definitions, then teach IR generation to
ignore non-explicit visibility when emitting declarations.  Use this to
make sure that RTTI, vtables, and VTTs get the right visibility.

More of rdar://problem/8613093

llvm-svn: 117781