llvm-svn: 135591

llvm-svn: 135590

llvm-svn: 135587

llvm-svn: 135586

llvm-svn: 135585

llvm-svn: 135584

llvm-svn: 135581

- Introduce JITDefault code model. This tells targets to set different default
  code model for JIT. This eliminates the ugly hack in TargetMachine where
  code model is changed after construction.

llvm-svn: 135580

away (since it comes in through Casting.h).  This will have to wait for another
day when I'm unmotivated though, or someone else to pick it up :)

llvm-svn: 135579

llvm-svn: 135578

llvm-svn: 135577

some common llvm types: stringref and smallvector.  This cleans up the codebase
quite a bit.

llvm-svn: 135576

llvm-svn: 135575

clang namespace.  There are a number of LLVM types that are used pervasively
and it doesn't make sense to keep qualifying them.  Start with casting
operators.

llvm-svn: 135574

llvm-svn: 135573

This is something of a hack, the problem is as follows:

1. we instantiate both copied of RetainPtr with the two different argument types
   (an id and protocol-qualified id).
2. We refer to the ctor of one of the instantiations when introducing global "x",
   this causes us to emit an llvm::Function for a prototype whose "this" has type
   "RetainPtr<id<bork> >*".
3. We refer to the ctor of the other instantiation when introducing global "y",
   however, because it *mangles to the same name as the other ctor* we just use
   a bitcasted version of the llvm::Function we previously emitted.
4. We emit deferred declarations, causing us to emit the body of the ctor, however
   the body we emit is for RetainPtr<id>, which expects its 'this' to have an IR
   type of "RetainPtr<id>*".

Because of the mangling collision, we don't have this case, and explode.

This is really some sort of weird AST invariant violation or something, but hey
a bitcast makes the pain go away.

llvm-svn: 135572

It doesn't matter in practice, but it is good to be tidy.

llvm-svn: 135571

llvm-svn: 135570

TargetLoweringObjectFileImpl down to MCObjectFileInfo.

TargetAsmInfo is done to one last method. It's *almost* gone!

llvm-svn: 135569

llvm-svn: 135568

and ConvertTypeForMem are the same for pointers, it is best to just
use ConvertType.  Thanks Eli!

llvm-svn: 135567

info. Holding Use* pointers is bad form even though it happened to
work in this case.

llvm-svn: 135566

decaying an array of incomplete type (which has type [0 x i8]*) to a
normal pointer (which has incompletetype*).

llvm-svn: 135565

X86Subtarget.h: Assume "x86_64-cygwin", though it has not been released yet, to appease test/CodeGen/X86 on cygwin.

llvm-svn: 135564

Also we now display a live update of the kexts that we are loading.

llvm-svn: 135563

llvm-svn: 135562

llvm-svn: 135561

llvm-svn: 135560

llvm-svn: 135559

llvm-svn: 135558

llvm-svn: 135557

the AST reader down to the AST file + local ID, rather than walking
the PCH chain. More cleanup/generalization, although there is more
work to do for preprocessed entities. In particular, the
"preallocation" scheme for preprocessed entities is not going to work
well with late loading of PCH files, and it's likely we'll have to do
something akin to the SourceManager's negative/positive loading.

llvm-svn: 135556

llvm-svn: 135555

reader down to the AST file + local ID, rather than walking the PCH
chain. No functionality change; this is generalization and cleanup.

llvm-svn: 135554

llvm-svn: 135553

arguments.

llvm-svn: 135552

AST reader down to the AST file + local ID, rather than walking the
PCH chain. No functionality change; this is generalization and cleanup.

llvm-svn: 135551

llvm-svn: 135550

llvm-svn: 135549

AST reader down to the AST file + local ID within that file, rather
than lamely walking the PCH chain. There's no actual functionality
change now, but this is cleaner and more general.

llvm-svn: 135548