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

I forgot to to do this in r184356. The only references were in APFloatTest.cpp.

llvm-svn: 184366

This is a precursor to fix a regression caused by PR14763/r183329 where
the location of a non-trivial pass-by-value parameter ends up
incorrectly referring directly to the parameter (a pointer) rather than
the object pointed to by the pointer.

llvm-svn: 184365

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

llvm-svn: 184359

[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

llvm-svn: 184355

llvm-svn: 184354

Store the individual fields we need instead of a sys::FileStatus.

llvm-svn: 184353

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

This is the first patch in a series of patches to rename isNormal =>
isFiniteNonZero and isIEEENormal => isNormal. In order to prevent careless
errors on my part the overall plan is:

1. Add the isFiniteNonZero predicate with tests. I can do this in a method
independent of isNormal. (This step is this patch).
2. Convert all references to isNormal with isFiniteNonZero. My plan is to
comment out isNormal locally and continually convert isNormal references =>
isFiniteNonZero until llvm/clang compiles.
3. Remove old isNormal and rename isIEEENormal to isNormal.
4. Look through all of said references from patch 2 and see if we can simplify
them by using the new isNormal.

llvm-svn: 184350

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: 184348

llvm-svn: 184346

I have had several requests to expose these two methods as public for various
potential optimizations.

llvm-svn: 184345

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: 184338

This matches GNU ar behavior. Also remove the now unused getFileStatus method.
Not sure how to add a test, it would have to run ls -l or something like that.

llvm-svn: 184337

llvm-svn: 184328

llvm-svn: 184325

llvm-svn: 184320

llvm-svn: 184318

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: 184316

llvm-svn: 184315

llvm-svn: 184311

It is not present in GNU or OS X versions and doesn't make a lot of sense
for llvm-ar.

llvm-svn: 184306

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