llvm-svn: 163225

Fixed the DAG combiner to better handle the folding of AND nodes for vector types. The previous code was making the assumption that the length of the bitmask returned by isConstantSplat was equal to the size of the vector type. Now we first make sure that the splat value has at least the length of the vector lane type, then we only use as many fields as we have available in the splat value.

llvm-svn: 163203

llvm-svn: 163194

Convert vextracti128/vextractf128 intrinsics to extract_subvector at DAG build time. Similar was previously done for vinserti128/vinsertf128. Add patterns for folding these extract_subvectors with stores.

llvm-svn: 163192

Implicit uses can be dynamically tied to defs. This will soon be used
for predicated instructions on ARM.

llvm-svn: 163177

llvm-svn: 163154

The MachineOperand::TiedTo field was maintained, but not used.

This patch enables it in isRegTiedToDefOperand() and
isRegTiedToUseOperand() which are the actual functions use by the
register allocator.

llvm-svn: 163153

llvm-svn: 163152

After much agonizing, use a full 4 bits of precious MachineOperand space
to encode this. This uses existing padding, and doesn't grow
MachineOperand beyond its current 32 bytes.

This allows tied defs among the first 15 operands on a normal
instruction, just like the current MCInstrDesc constraint encoding.
Inline assembly needs to be able to tie more than the first 15 operands,
and gets special treatment.

Tied uses can appear beyond 15 operands, as long as they are tied to a
def that's in range.

llvm-svn: 163151

- CodeGenPrepare pass for identifying div/rem ops
- Backend specifies the type mapping using addBypassSlowDivType
- Enabled only for Intel Atom with O2 32-bit -> 8-bit
- Replace IDIV with instructions which test its value and use DIVB if the value
is positive and less than 256.
- In the case when the quotient and remainder of a divide are used a DIV
and a REM instruction will be present in the IR. In the non-Atom case
they are both lowered to IDIVs and CSE removes the redundant IDIV instruction,
using the quotient and remainder from the first IDIV. However,
due to this optimization CSE is not able to eliminate redundant
IDIV instructions because they are located in different basic blocks.
This is overcome by calculating both the quotient (DIV) and remainder (REM)
in each basic block that is inserted by the optimization and reusing the result
values when a subsequent DIV or REM instruction uses the same operands.
- Test cases check for the presents of the optimization when calculating
either the quotient, remainder,  or both.

Patch by Tyler Nowicki!

llvm-svn: 163150

No functionality change.

llvm-svn: 163115

Fixs PR13719.

llvm-svn: 163107

llvm-svn: 163094

llvm-svn: 163086

Only legalise a VSELECT in to bitwise operations if the vector mask bool is zeros or all ones.  A vector bool with just ones isn't suitable for masking with.

No test case unfortunately as i couldn't find a target which fit all
the conditions needed to hit this code.

llvm-svn: 163075

Revert "Take account of boolean vector contents when promoting a build vector from i1 to some other type.  rdar://problem/12210060"

This reverts commit 5dd9e214fb92847e947f9edab170f9b4e52b908f.

Thanks to Duncan for explaining how this should have been done.

Conflicts:

	test/CodeGen/X86/vec_select.ll

llvm-svn: 163064

llvm-svn: 163059

llvm-svn: 163051

llvm-svn: 163049

Manage tied operands entirely internally to MachineInstr. This makes it
possible to change the representation of tied operands, as I will do
shortly.

The constraint that tied uses and defs must be in the same order was too
restrictive.

llvm-svn: 163021

Use CloneMachineInstr to make a new MI in commuteInstruction to make the code tolerant of instructions with more than two input operands.

llvm-svn: 163000

I was too optimistic, inline asm can have tied operands that don't
follow the def order.

Fixes PR13742.

llvm-svn: 162998

Take account of boolean vector contents when promoting a build vector from i1 to some other type.  rdar://problem/12210060

llvm-svn: 162960

Teach the DAG combiner to turn chains of FADDs (x+x+x+x+...) into FMULs by constants.  This is only enabled in unsafe FP math mode, since it does not preserve rounding effects for all such constants.

llvm-svn: 162956

Currently targets that do not support selects with scalar conditions and vector operands - scalarize the code. ARM is such a target
because it does not support CMOV of vectors. To implement this efficientlyi, we broadcast the condition bit and use a sequence of NAND-OR
to select between the two operands. This is the same sequence we use for targets that don't have vector BLENDs (like SSE2).

rdar://12201387

llvm-svn: 162926

When a MachineInstr is constructed, its implicit operands are added
first, then the explicit operands are inserted before the implicits.

MCInstrDesc has oprand flags like early clobber and operand ties that
apply to the explicit operands.

Don't look at those flags when the implicit operands are first added in
the explicit operands's positions.

llvm-svn: 162910

Add FMA to switch statement in VectorLegalizer::LegalizeOp so that it can be expanded when it isn't legal.

llvm-svn: 162894

llvm-svn: 162893

When there are multiple tied use-def pairs on an inline asm instruction,
the tied uses must appear in the same order as the defs.

It is possible to write an LLVM IR inline asm instruction that breaks
this constraint, but there is no reason for a front end to emit the
operands out of order.

The gnu inline asm syntax specifies tied operands as a single read/write
constraint "+r", so ouf of order operands are not possible.

llvm-svn: 162878

For normal instructions, isTied() is set automatically by addOperand(),
based on MCInstrDesc, but inline asm has tied operands outside the
descriptor.

llvm-svn: 162869

Ordered memory operations are more constrained than volatile loads and
stores because they must be ordered with respect to all other memory
operations.

llvm-svn: 162861

It is technically allowed to move a normal load across a volatile load,
but probably not a good idea.

It is not allowed to move a load across an atomic load with
Ordering > Monotonic, and we model those with MOVolatile as well.

I recently removed the mayStore flag from atomic load instructions, so
they don't need a pseudo-opcode. This patch makes up for the difference.

llvm-svn: 162857

The operands on an INLINEASM machine instruction are divided into groups
headed by immediate flag operands. Verify this structure.

Extract verifyTiedOperands(), and only call it for non-inlineasm
instructions.

llvm-svn: 162849

llvm-svn: 162848

WHen running with -verify-machineinstrs, check that tied operands come
in matching use/def pairs, and that they are consistent with MCInstrDesc
when it applies.

llvm-svn: 162816

The isTied bit is set automatically when a tied use is added and
MCInstrDesc indicates a tied operand. The tie is broken when one of the
tied operands is removed.

llvm-svn: 162814

While in SSA form, a MachineInstr can have pairs of tied defs and uses.
The tied operands are used to represent read-modify-write operands that
must be assigned the same physical register.

Previously, tied operand pairs were computed from fixed MCInstrDesc
fields, or by using black magic on inline assembly instructions.

The isTied flag makes it possible to add tied operands to any
instruction while getting rid of (some of) the inlineasm magic.

Tied operands on normal instructions are needed to represent predicated
individual instructions in SSA form. An extra <tied,imp-use> operand is
required to represent the output value when the instruction predicate is
false.

Adding a predicate to:

  %vreg0<def> = ADD %vreg1, %vreg2

Will look like:

  %vreg0<tied,def> = ADD %vreg1, %vreg2, pred:3, %vreg7<tied,imp-use>

The virtual register %vreg7 is the value given to %vreg0 when the
predicate is false. It will be assigned the same physreg as %vreg0.

This commit adds the isTied flag and sets it based on MCInstrDesc when
building an instruction. The flag is not used for anything yet.

llvm-svn: 162774

Register operands are manipulated by a lot of target-independent code,
and it is not always possible to preserve target flags. That means it is
not safe to use target flags on register operands.

None of the targets in the tree are using register operand target flags.
External targets should be using immediate operands to annotate
instructions with operand modifiers.

llvm-svn: 162770

These extra flags are not required to properly order the atomic
load/store instructions. SelectionDAGBuilder chains atomics as if they
were volatile, and SelectionDAG::getAtomic() sets the isVolatile bit on
the memory operands of all atomic operations.

The volatile bit is enough to order atomic loads and stores during and
after SelectionDAG.

This means we set mayLoad on atomic_load, mayStore on atomic_store, and
mayLoad+mayStore on the remaining atomic read-modify-write operations.

llvm-svn: 162733

In SelectionDAGLegalize::ExpandLegalINT_TO_FP, expand INT_TO_FP nodes without
using any f64 operations if f64 is not a legal type.

Patch by Stefan Kristiansson. 

llvm-svn: 162728