This reverts commit r191670.

It was causing build failures on the msvc bots:

http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/5166/steps/compile/logs/stdio

llvm-svn: 191679

[ARM] Assembler: ARM LDRD with writeback requires the base register to be different from the destination registers.

See ARM ARM A8.8.72.

Violating this constraint results in unpredictable behavior.

llvm-svn: 191678

Those writes really need two/three uops.

llvm-svn: 191677

llvm-svn: 191676

llvm-svn: 191675

Defines away the issue where cast<Instruction> would fail because constant
folding happened. Also slightly cleaner.

llvm-svn: 191674

Inspired by the object from the SLPVectorizer. This found a minor bug in the
debug loc restoration in the vectorizer where the location of a following
instruction was attached instead of the location from the original instruction.

llvm-svn: 191673

They don't depend on the templated stuff.

llvm-svn: 191672

For targets that have instruction itineraries this means no change. Targets
that move over to the new schedule model will use be able the new schedule
module for instruction latencies in the if-converter (the logic is such that if
there is no itineary we will use the new sched model for the latencies).

Before, we queried "TTI->getInstructionLatency()" for the instruction latency
and the extra prediction cost. Now, we query the TargetSchedule abstraction for
the instruction latency and TargetInstrInfo for the extra predictation cost. The
TargetSchedule abstraction will internally call "TTI->getInstructionLatency" if
an itinerary exists, otherwise it will use the new schedule model.

ATTENTION: Out of tree targets!

(I will also send out an email later to LLVMDev)

This means, if your target implements

 unsigned getInstrLatency(const InstrItineraryData *ItinData,
                          const MachineInstr *MI,
                          unsigned *PredCost);

and returns a value for "PredCost", you now also need to implement

 unsigned getPredictationCost(const MachineInstr *MI);

(if your target uses the IfConversion.cpp pass)

radar://15077010

llvm-svn: 191671

Enable building the LTO library (.lib and.dll) and llvm-lto.exe on Windows with
MSVC and Mingw as well as re-enabling the associated test.

Patch by Greg Bedwell!

llvm-svn: 191670

when it was actually a Constant*.

There are quite a few other casts to Instruction that might have the same problem,
but this is the only one I have a test case for.

llvm-svn: 191668

llvm-svn: 191664

For some reason, adding definitions for these load and store
instructions changed whether some of the build bots matched
comparisons as signed or unsigned.

llvm-svn: 191663

llvm-svn: 191661

The only thing this does on its own is make the definitions of RISB[HL]G
a bit more precise.  Those instructions are only used by the MC layer at
the moment, so no behavioral change is intended.  The class is needed by
later patches though.

llvm-svn: 191660

Use subreg_hNN and subreg_lNN for the high and low NN bits of a register.
List the low registers first, so that subreg_l32 also means the low 32
bits of a 128-bit register.

Floats are stored in the upper 32 bits of a 64-bit register, so they
should use subreg_h32 rather than subreg_l32.

No behavioral change intended.

llvm-svn: 191659

It now points to the equivalent page on imgtec.com

llvm-svn: 191658

llvm-svn: 191656

I'm about to add support for high-word operations, so it seemed better
for the low-word registers to have names like R0L rather than R0W.
No behavioral change intended.

llvm-svn: 191655

Filter out repeated sections from the X86 disassembler modRMTable. Saves about ~43K from a released build. Unfortunately the disassembler tables are still upwards of 800K.

llvm-svn: 191652

Add a few more FMA4 disassembler test cases to match the scalar set with regards to combinations of L and W-bits.

llvm-svn: 191650

Add VEX_LIG to scalar FMA4 instructions.
Use VEX_LIG in some of the inheriting checks in disassembler table generator.
Make use of VEX_L_W, VEX_L_W_XS, VEX_L_W_XD contexts.
Don't let VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE inherit from their non-L forms unless VEX_LIG is set.
Let VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE inherit from all of their non-L or non-W cases.
Increase ranking on VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE so they get chosen over non-L/non-W forms.

llvm-svn: 191649

Those can occur in dead code. PR17402.

llvm-svn: 191644

llvm-svn: 191643

llvm-svn: 191638

llvm-svn: 191637

SDNode destructors are never called. As an optimization use AtomicSDNode's
internal storage if we have a small number of operands.

llvm-svn: 191636

llvm-svn: 191633

llvm-svn: 191632

llvm-svn: 191630

llvm-svn: 191628

out in projects. This appears to be working on my system, and I will be
watching build bots to see if there are any issues on other platforms.

llvm-svn: 191624

llvm-svn: 191611

llvm-svn: 191610

llvm-svn: 191604

We were completely ignoring the unorder/ordered attributes of condition
codes and also incorrectly lowering seto and setuo.

Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 191603

SelectionDAG will now attempt to inverse an illegal conditon in order to
find a legal one and if that doesn't work, it will attempt to swap the
operands using the inverted condition.

There are no new test cases for this, but a nubmer of the existing R600
tests hit this path.

llvm-svn: 191602

This is useful for targets like R600, which only support GT, GE, NE, and EQ
condition codes as it removes the need to handle unsupported condition
codes in target specific code.

There are no tests with this commit, but R600 has been updated to take
advantage of this new feature, so its existing selectcc tests are now
testing the swapped operands path.

llvm-svn: 191601

Interpreting the results of this function is not very intuitive, so I
cleaned it up to make it more clear whether or not a SETCC op was
legalized and how it was legalized (either by swapping LHS and RHS or
replacing with AND/OR).

This patch does change functionality in the LHS and RHS swapping case,
but unfortunately there are no in-tree tests for this.  However, this
patch is a prerequisite for R600 to take advantage of the LHS and RHS
swapping, so tests will be added in subsequent commits.

llvm-svn: 191600

llvm-svn: 191597