There is still a bit more refactoring left to do in Targets. But we are now very
close to fixing all the layering issues in MC.

llvm-svn: 135611

llvm-svn: 135610

llvm-svn: 135609

- Not great yet, but it's a start.
- Requires an object file with a symbol table. (I really want to fix this, but it'll need a whole new algorithm)
- ELF and COFF won't work at the moment due to libObject shortcomings.

To try it out run
$ llvm-objdump -d --cfg foo.o

This will create a graphviz file for every symbol in the object file's text section containing a CFG.

llvm-svn: 135608

llvm-svn: 135607

llvm-svn: 135606

llvm-svn: 135605

x86_64-pc-win32-macho is used in conjunction with -no-integrated-as go ahead and
use the Darwin system assembler.
rdar://9785470

llvm-svn: 135604

llvm-svn: 135602

llvm-svn: 135601

llvm-svn: 135600

llvm-svn: 135599

of Apple gcc build which produces wrong namespace for std::string in debug info.

llvm-svn: 135597

Correctly handle 's' bit and predication suffices. Add parsing and encoding
tests.

llvm-svn: 135596

llvm-svn: 135595

This should fix the spurious buildbot errors.

llvm-svn: 135594

fails because of lifetime differences of parameter and argument type.
// rdar://9790531

llvm-svn: 135593

llvm-svn: 135592

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