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

alignment requirements of the new alloca. As one consequence which was
reported as a bug by Duncan, we overaligned memcpy calls to ranges of
allocas after they were rewritten to types with lower alignment
requirements. Other consquences are possible, but I don't have any test
cases for them.

llvm-svn: 164937

llvm-svn: 164935

Fixes PR13985.

llvm-svn: 164934

could probably be factored still further to hoist this logic into
a generic helper, but currently I don't have particularly clean ideas
about how to handle that.

This at least allows us to drop custom load rewriting from the
speculation logic, which in turn allows the existing load rewriting
logic to fire. In theory, this could enable vector promotion or other
tricks after speculation occurs, but I've not dug into such issues. This
is primarily just cleaning up the factoring of the code and the
resulting logic.

llvm-svn: 164933

llvm-svn: 164926

a pair of instructions, one for the used pointer and the second for the
user. This simplifies the representation and also makes it more dense.

This was noticed because of the miscompile in PR13926. In that case, we
were running up against a fundamental "bad idea" in the speculation of
PHI and select instructions: the speculation and rewriting are
interleaved, which requires phi speculation to also perform load
rewriting! This is bad, and causes us to miss opportunities to do (for
example) vector rewriting only exposed after PHI speculation, etc etc.
It also, in the old system, required us to insert *new* load uses into
the current partition's use list, which would then be ignored during
rewriting because we had already extracted an end iterator for the use
list. The appending behavior (and much of the other oddities) stem from
the strange de-duplication strategy in the PartitionUse builder.
Amusingly, all this went without notice for so long because it could
only be triggered by having *different* GEPs into the same partition of
the same alloca, where both different GEPs were operands of a single
PHI, and where the GEP which was not encountered first also had multiple
uses within that same PHI node... Hence the insane steps required to
reproduce.

So, step one in fixing this fundamental bad idea is to make the
PartitionUse actually contain a Use*, and to make the builder do proper
deduplication instead of funky de-duplication. This is enough to remove
the appending behavior, and fix the miscompile in PR13926, but there is
more work to be done here. Subsequent commits will lift the speculation
into its own visitor. It'll be a useful step toward potentially
extracting all of the speculation logic into a generic utility
transform.

The existing PHI test case for repeated operands has been made more
extreme to catch even these issues. This test case, run through the old
pass, will exactly reproduce the miscompile from PR13926. ;] We were so
close here!

llvm-svn: 164925

No functionality change.

llvm-svn: 164924

SimplifyCFG: Enumerating all predecessors of a BB can be expensive (switches), avoid it if possible.

No functionality change.

llvm-svn: 164923

llvm-svn: 164922

bad.  Fonts already have appropriate tracking built-in.

llvm-svn: 164921

llvm-svn: 164920

Change getX86SubSuperRegister to take an MVT::SimpleValueType rather than an EVT and add llvm_unreachable to the switches. Helps it compile to dramatically better code.

llvm-svn: 164919