Fix up three tests - one that was relying on abbreviation number,
another relying on a location list in this case (& testing raw asm,
changed that to use dwarfdump on the debug_info now that that's where
the location is), and another which was added in r184368 - exposing a
bug in that fix that is exposed when we emit the location inline rather
than through a location list. Fix that bug while I'm here.

llvm-svn: 184387

[Support/CrashRecoveryContext] Make sure CrashRecoveryContext does not clear the thread-local "CurrentContext"
in the "parent" thread, when we are using CrashRecoveryContext::RunSafelyOnThread.

When using CrashRecoveryContext::RunSafelyOnThread, we would set a CrashRecoveryContextImpl* to a thread-local variable
for the "child" thread, but CrashRecoveryContext would erroneously clear it in the "parent" thread.

The result was that if CrashRecoveryContext::RunSafelyOnThread was called again in the "child" thread it would mess up
crash-recovery for its parent.

A test for this will be added in the clang repository.
rdar://14204560

llvm-svn: 184380

llvm-svn: 184376

llvm-svn: 184373

llvm-svn: 184369

We had been papering over a problem with location info for non-trivial
types passed by value by emitting their type as references (this caused
the debugger to interpret the location information correctly, but broke
the type of the function). r183329 corrected the type information but
lead to the debugger interpreting the pointer parameter as the value -
the debug info describing the location needed an extra dereference.

Use a new flag in DIVariable to add the extra indirection (either by
promoting an existing DW_OP_reg (parameter passed in a register) to
DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n
(parameter passed on the stack).

llvm-svn: 184368

llvm-svn: 184362

This is a basic implementation - we still don't have any support (that I
know of) for dumping DWARF expressions in a meaningful way, so the
location information itself is just printed as a sequence of bytes as we
do elsewhere.

llvm-svn: 184361

Access the TargetLoweringInfo from the TargetMachine object instead of caching it. The TLI may change between functions. No functionality change.

llvm-svn: 184360

[MC/DWARF] Generate multiple .debug_line entries for adjacent .loc directives

The compiler occasionally generates multiple .loc directives in a row
(at the same instruction address).  These need to be transformed into
multple actual .debug_line table entries, since they are used to signal
certain information to the debugger (e.g. if the opening brace of a
function body is on the same line as the declaration).

The MCAsmStreamer version of EmitDwarfLocDirective handles this
correctly by emitting a .loc directive every time it is called.
However, the MCObjectStream version simply defaults to recording
the information and emitting only a single table entry later,
e.g. when EmitInstruction is called.

This patch introduces a MCAsmStreamer::EmitDwarfLocDirective
version that emits a line table entry for a .loc directive
that may already be pending before recording the new directive.
(This is similar to how this is handled in GNU as.)

With this patch (and the code alignment factor patch) applied,
I'm now getting identical DWARF .debug sections for all test-suite
object files on PowerPC for the internal and the external assembler.

llvm-svn: 184357

Turns out all the references were in llvm and not in clang.

llvm-svn: 184356

Access the TargetLoweringInfo from the TargetMachine object instead of caching it. The TLI may change between functions. No functionality change.

llvm-svn: 184352

Modified the implementation of fs::GetUniqueID on Windows such that it actually finds a unique identifier for a file.  Also adds unit tests for GetUniqueID.

llvm-svn: 184351

Access the TargetLoweringInfo from the TargetMachine object instead of caching it. The TLI may change between functions. No functionality change.

llvm-svn: 184349

llvm-svn: 184346

llvm-svn: 184344

Register it with PassManager

llvm-svn: 184343

Prior to this change, the considered addressing modes may be invalid since the
maximum and minimum offsets were not taking into account.
This was causing an assertion failure.

The added test case exercices that behavior.

<rdar://problem/14199725> Assertion failed: (CurScaleCost >= 0 && "Legal
addressing mode has an illegal cost!")

llvm-svn: 184341

llvm-svn: 184325

The type <3 x i8> is a common in graphics and we want to be able to vectorize it.

This changes accelerates bullet by 12% and 471_omnetpp by 5%.

llvm-svn: 184317

llvm-svn: 184311

llvm-svn: 184305

llvm-svn: 184298

The RenderMethod field in RegisterOperand class sets the name of the method on the target specific operand to call to add the target specific operand to an MCInst. This patch defines RenderMethod for mips RegisterOperand classes and removes redundant code from MipsAsmParser.cpp

llvm-svn: 184292

llvm-svn: 184291

llvm-svn: 184286

llvm-svn: 184282

llvm-svn: 184281

llvm-svn: 184268

llvm-svn: 184263

llvm-svn: 184261

Currently, we only output the name.

llvm-svn: 184255

rdar://14194152

llvm-svn: 184244

llvm-svn: 184239

llvm-svn: 184235

llvm-svn: 184233

[ARMTargetLowering] ARMISD::{SUB,ADD}{C,E} second result is a boolean implying that upper bits are always 0.

llvm-svn: 184231

Said assert assumes that ADDC will always have a glue node as its second
argument and is checked before we even know that we are actually performing the
relevant MLAL optimization. This is incorrect since on ARM we *CAN* codegen ADDC
with a use list based second argument. Thus to have both effects, I converted
the assert to a conditional check which if it fails we do not perform the
optimization.

In terms of tests I can not produce an ADDC from the IR level until I get in my
multiprecision optimization patch which is forthcoming. The tests for said patch
would cause this assert to fail implying that said tests will provide the
relevant tests.

llvm-svn: 184230

llvm-svn: 184229

llvm-svn: 184228