No functional change.

llvm-svn: 163339

The RegisterCoalescer understands overlapping live ranges where one
register is defined as a copy of the other. With this change, register
allocators using LiveRegMatrix can do the same, at least for copies
between physical and virtual registers.

When a physreg is defined by a copy from a virtreg, allow those live
ranges to overlap:

  %CL<def> = COPY %vreg11:sub_8bit; GR32_ABCD:%vreg11
  %vreg13<def,tied1> = SAR32rCL %vreg13<tied0>, %CL<imp-use,kill>

We can assign %vreg11 to %ECX, overlapping the live range of %CL.

llvm-svn: 163336

We will soon allow virtual register live ranges to overlap regunit live
ranges when the physreg is defined as a copy of the virtreg:

  %EAX = COPY %vreg5
  FOO %vreg5
  BAR %EAX<kill>

There is no real interference since %vreg5 and %EAX have the same value
where they overlap.

This patch prevents addKillFlags from adding virtreg kill flags to FOO
where the assigned physreg is overlapping the virtual register live
range.

llvm-svn: 163335

Kill flags are difficult to maintain, and liveness queries are better
handled by live intervals.

Kill flags are reinserted after register allocation by addKillFlags().

llvm-svn: 163334

llvm-svn: 163324

llvm-svn: 163316

llvm-svn: 163309

Add a new optimization pass: Stack Coloring, that merges disjoint static allocations (allocas). Allocas are known to be
disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics).

llvm-svn: 163299

llvm-svn: 163273

llvm-svn: 163263

llvm-svn: 163258

MachineInstr.

llvm-svn: 163257

llvm-svn: 163256

of its constness. Found by gcc48 -Wcast-qual.

llvm-svn: 163254

llvm-svn: 163243

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