llvm-svn: 134094

llvm-svn: 134093

The tSpill and tRestore instructions are just copies of the tSTRspi and
tLDRspi instructions, respectively. Just use those directly instead.

llvm-svn: 134092

accessibility of an initializer which is a compound 
statement. // rdar://9694706

llvm-svn: 134091

looking up what we needed by address, which is much faster.

llvm-svn: 134090

llvm-svn: 134089

getRegForInlineAsmConstraint.

Part of rdar://9643582

llvm-svn: 134088

llvm-svn: 134087

creating a few specific register classes.

Part of rdar://9643582

llvm-svn: 134086

for the port.

Part of rdar://9643582

llvm-svn: 134085

Part of rdar://9643582

llvm-svn: 134084

Part of rdar://9643582

llvm-svn: 134083

replacing -freset-local-blocks. // rdar://9227352

llvm-svn: 134082

changes that caused all SBValue objects to completely ignore the target
lock due to bad C++ scoping of the target Mutex::Locker variables.

llvm-svn: 134081

getRegForInlineAsmConstraint.

Part of rdar://9643582

llvm-svn: 134080

via vectors.

Part of rdar://9643582

llvm-svn: 134079

llvm-svn: 134078

llvm-svn: 134072

lifetime intrinsics" due to buildbot failures.

llvm-svn: 134071

llvm-svn: 134070

For example, ".byte 256" would previously assert() when emitting an object
file. Now it generates a diagnostic that the literal value is out of range.

rdar://9686950

llvm-svn: 134069

llvm-svn: 134068

llvm-svn: 134067

Make ARC support default to true.  Please can we stop making Objective-C runtime features part of the platform description?  This only makes sense for Darwin.

llvm-svn: 134066

llvm-svn: 134065

Change AsmName's type from StringRef to std::string. AsmName was pointing to a temporary string object that was destroyed. This is undefined behavior and MSVC didn't like it.

This fixes over 300+ failing tests on MSVC.
Credit for this fix goes to chapuni.

llvm-svn: 134064

We don't pass classes with a copy-constructor or destructor byval, so the address takes up an integer register (if one is available).  Make sure the x86-64 ABI implementation takes that into account properly.

The fixed implementation is compatible with the implementation both gcc and llvm-gcc use.

rdar://9686430 . (This is the issue that was reported in the thread "[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable".)

llvm-svn: 134059

llvm-svn: 134057

llvm-svn: 134056

llvm-svn: 134055

mean they can be removed.

llvm-svn: 134054

miscompile.

llvm-svn: 134053

llvm-svn: 134052

llvm-svn: 134050

llvm-svn: 134049

llvm-svn: 134048

This function has to deal with a lot of special cases, and the old
version got it wrong sometimes. In particular, it would sometimes leave
multiple uses in the stack interval in a single block. That causes bad
code with multiple reloads in the same basic block.

The new version handles block entry and exit in a single pass. It first
eliminates all the easy cases, and then goes on to create a local
interval for the blocks with difficult interference. Previously, we
would only create the local interval for completely isolated blocks.

It can happen that the stack interval becomes completely empty because
we could allocate a register in all edge bundles, and the new local
intervals deal with the interference. The empty stack interval is
harmless, but we need to remove a SplitKit assertion that checks for
empty intervals.

llvm-svn: 134047

llvm-svn: 134046

wipe out stack blocks when they go out of scope.
// rdar://9227352

llvm-svn: 134045

llvm-svn: 134042