llvm-svn: 165069

The mips 64bit instructions DSLL, DSRA, DSRL, DEXT and DINS get transformed by the assembler or through codegen direct object output to other variants based on the value of the immediate values of the operands.

If the code is generated as assembler, this transformation does not occur assuming that it will occur later in the assembler.

This code was originally called from  MipsAsmPrinter.cpp and we needed to check for OutStreamer.hasRawTextSupport(). This was not a good place for it and has been moved to MCTargetDesc/MipsMCCodeEmitter.cpp where both direct object and the assembler use it it automagically.

The test cases have been checked in for a number of weeks now.

llvm-svn: 165067

scheduled for processing on the worklist eventually gets deleted while
we are processing another alloca, fixing the original test case in
PR13990.

To facilitate this, add a remove_if helper to the SetVector abstraction.
It's not easy to use the standard abstractions for this because of the
specifics of SetVectors types and implementation.

Finally, a nice small test case is included. Thanks to Benjamin for the
fantastic reduced test case here! All I had to do was delete some empty
basic blocks!

llvm-svn: 165065

also makes it more consistent with Clang and several passes' doxygen
style.

llvm-svn: 165064

llvm-svn: 165063

The new algorithm has been enabled by default for almost a week now and
seems to be stable.

llvm-svn: 165062

Reserved register live ranges look like a set of dead defs - any uses of
reserved registers are ignored.

Instead of skipping the updating of reserved register operands entirely,
just ignore the use operands and treat the def operands normally.

No test case, handleMove() is not commonly used yet.

llvm-svn: 165060

of operand is specific to MS-style inline assembly and should not be generated
when parsing normal assembly.

The purpose of the wildcard operands are to allow the AsmParser to match
multiple instructions (i.e., MCInsts) to a given ms-style asm statement.  For
the time being the matcher just returns the first match.  This patch only
implements wildcard matches for memory operands.  Support for register
wildcards will be added in the near future.

llvm-svn: 165057

JoinVals::pruneValues() calls LIS->pruneValue() to avoid conflicts when
overlapping two different values. This produces a set of live range end
points that are used to reconstruct the live range (with SSA update)
after joining the two registers.

When a value is pruned twice, the set of end points was insufficient:

  v1 = DEF
  v1 = REPLACE1
  v1 = REPLACE2
  KILL v1

The end point at KILL would only reconstruct the live range from
REPLACE2 to KILL, leaving the range REPLACE1-REPLACE2 dead.

Add REPLACE2 as an end point in this case so the full live range is
reconstructed.

This fixes PR13999.

llvm-svn: 165056

llvm-svn: 165055

llvm-svn: 165054

llvm-svn: 165053

prologue. Also skip frame setup instructions when looking for the
first location.

llvm-svn: 165052

llvm-svn: 165051

in the block.

llvm-svn: 165050

with just an insert point from the MachineBasicBlock and let
the location be updated as we access it.

llvm-svn: 165049

llvm-svn: 165042

llvm-svn: 165038

We require that the indices into the use lists are stable in order to
build fast lookup tables to locate a particular partition use from an
operand of a PHI or select. This is (obviously in hind sight)
incompatible with erasing elements from the array. Really, we don't want
to erase anyways. It is expensive, and a rare operation. Instead, simply
weaken the contract of the PartitionUse structure to allow null Use
pointers to represent dead uses. Now we can clear out the pointer to
mark things as dead, and all it requires is adding some 'continue'
checks to the various loops.

I'm still reducing a test case for this, as the test case I have is
huge. I think this one I can get a nice test case for though, as it was
much more deterministic.

llvm-svn: 165032

This adds 'elf' as a recognized target triple environment value and overrides the default generated object format on Windows platforms if that value is present.  This patch also enables MCJIT tests on Windows using the new environment value.

llvm-svn: 165030

being separate was that it can grow the use list. As a consequence, we
can't use the iterator-pair interface, we need an index based interface.
Expose such an interface from the AllocaPartitioning, and use it in the
speculator.

This should at least fix a use-after-free bug found by Duncan, and may
fix some of the other crashers.

I don't have a nice deterministic test case yet, but if I get a good
one, I'll add it.

llvm-svn: 165027

llvm-svn: 165019

the add/sub case since in the case of multiplication you also have to check that
the operation in the larger type did not overflow.

llvm-svn: 165017

Patch by David Tweed!

llvm-svn: 164996

Again, let me know if anything breaks due to this!

llvm-svn: 164986

llvm-svn: 164983

map constraints and MCInst operands to inline asm operands.  This replaces the
getMCInstOperandNum() function.

The logic to determine the constraints are not in place, so we still default to
a register constraint (i.e., "r"). Also, we no longer build the MCInst but
rather return just the opcode to get the MCInstrDesc.

llvm-svn: 164979

llvm-svn: 164975

The target backend can support data-in-code load commands even when
the assembler doesn't, or vice-versa. Allow targets to opt-in for
direct-to-object.

PR13973.

llvm-svn: 164974

llvm-svn: 164972

llvm-svn: 164969

llvm-svn: 164964

The Apple buildbots have been modified not to pass --target,
so they shouldn't choke on a default program prefix anymore.

Patch by Rick Foos!

llvm-svn: 164956

llvm-svn: 164949

llvm-svn: 164948

- Update maximal stack alignment when stack arguments are prepared before a
  call.
- Test cases are enhanced to show it's not a Win32 specific issue but a generic
  one.

llvm-svn: 164946

Reduces runtime of i386-large-relocations.s by 10x in Release builds, even more
in Debug+Asserts builds.

llvm-svn: 164945

llvm-svn: 164940

is the second time I've moved this comment around...)

llvm-svn: 164939

llvm-svn: 164938