llvm-svn: 191728

llvm-svn: 191715

on ADD16rr opcodes, if src1 != src, since that would cause 
convertToThreeAddress to try to create a virtual register. This is not
permitted after register allocation, which is when the X86FixupLEAs pass
runs.

This patch fixes PR16785.

llvm-svn: 191711

This patch adds Direct Object Emission support for I8 instructions: andi.b, bmnzi.b, bmzi.b, bseli.b, nori.b, ori.b, shf.{b,h,w} and xori.b.


Patch by Matheus Almeida

llvm-svn: 191688

This patch adds Direct Object Emission support for I5 instructions: addvi.{b,h,w,d}, ceqi.{b,h,w,d}, clei_s.{b,h,w,d}, clei_u.{b,h,w,d}, clti_s.{b,h,w,d}, clti_u.{b,h,w,d}, maxi_s.{b,h,w,d}, maxi_u.{b,h,w,d}, mini_s.{b,h,w,d}, mini_u.{b,h,w,d}, subvi.{b,h,w,d}.


Patch by Matheus Almeida

llvm-svn: 191687

Fix some LLVM Coding Standards violations.

No changes in functionality.

llvm-svn: 191686

This patch adds Direct Object Emission support for 2R instructions: nloc.{b,h,w}, nlzc.{b,h,w}, pcnt.{b,w,d}.  


Patch by Matheus Almeida

llvm-svn: 191685

 and not an MSA register

Patch by Matheus Almeida

llvm-svn: 191684

[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

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

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

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

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

llvm-svn: 191632

llvm-svn: 191630

llvm-svn: 191611

llvm-svn: 191610

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

llvm-svn: 191597

of loops.

Previously, two consecutive calls to function "func" would result in the
following sequence of instructions:

1. load $16, %got(func)($gp) // load address of lazy-binding stub.
2. move $25, $16
3. jalr $25                  // jump to lazy-binding stub.
4. nop
5. move $25, $16
6. jalr $25                  // jump to lazy-binding stub again.

With this patch, the second call directly jumps to func's address, bypassing
the lazy-binding resolution routine:

1. load $25, %got(func)($gp) // load address of lazy-binding stub.
2. jalr $25                  // jump to lazy-binding stub.
3. nop
4. load $25, %got(func)($gp) // load resolved address of func.
5. jalr $25                  // directly jump to func.

llvm-svn: 191591

resolved by lazy-binding.

llvm-svn: 191578

No intended functionality change.

llvm-svn: 191546

Phabricator code review is located here: http://llvm-reviews.chandlerc.com/D1750

llvm-svn: 191539

The backend tries to use block operations like MVC, NC, OC and XC for
simple scalar operations.  For correctness reasons, it rejects any case
in which the regions might partially overlap.  However, for performance
reasons, it should also reject cases where the regions might be equal,
since the instruction might then not use the fast path.

This fixes a performance regression seen in bzip2.  We may want to limit
the optimisation even more in future, or even remove it entirely, but I'll
try with this for now.

llvm-svn: 191525

The backend previously folded offsets into PC-relative addresses
whereever possible.  That's the right thing to do when the address
can be used directly in a PC-relative memory reference (using things
like LRL).  But if we have a register-based memory reference and need
to load the PC-relative address separately, it's better to use an anchor
point that could be shared with other accesses to the same area of the
variable.

Fixes a FIXME.

llvm-svn: 191524

This intrinsic is lowered into an equivalent INSERT_VECTOR_ELT which is
further lowered into a sequence of insert.w's on MIPS32.

llvm-svn: 191521

As specified in A8.8.72/A8.8.73/A8.8.74 in the ARM ARM, all variants of the ARM LDRD instruction have the following two constraints:

LDRD<c> <Rt>, <Rt2>, ...

(a) Rt must be even-numbered and not r14
(b) Rt2 must be R(t+1)

If those two constraints are not met the result of executing the instruction will be unpredictable.

Constraint (b) was already enforced, this commit adds support for constraint (a).

Fixes rdar://14479793.

llvm-svn: 191520

This intrinsic is lowered into an equivalent BUILD_VECTOR which is further
lowered into a sequence of insert.w's on MIPS32.

llvm-svn: 191519

This intrinsic is lowered into equivalent copy_s.w instructions during
legalization.

llvm-svn: 191518

No functional change.

llvm-svn: 191517

For v4f32 and v2f64, INSERT_VECTOR_ELT is matched by a pseudo-insn which is
later expanded to appropriate insve.[wd] insns.

llvm-svn: 191515

For v4f32 and v2f64, EXTRACT_VECTOR_ELT is matched by a pseudo-insn which may
be expanded to subregister copies and/or instructions as appropriate.

llvm-svn: 191514

llvm-svn: 191512