llvm-svn: 133174

This virtual function will replace allocation_order_begin/end as the one
to override when implementing custom allocation orders. It is simpler to
have one function return an ArrayRef than having two virtual functions
computing different ends of the same array.

Use getRawAllocationOrder() in place of allocation_order_begin() where
it makes sense, but leave some clients that look like they really want
the filtered allocation orders from RegisterClassInfo.

llvm-svn: 133170

llvm-svn: 133124

Function::getNumBlockIDs() should be used instead of Function::size() to set the upper limit on the block IDs since basic blocks might get removed (simplified away) after being initially numbered. Plus the test case, in which SelectionDAGBuilder::visitBr() calls llvm::MachineFunction::removeFromMBBNumbering(), which introduces the hole in numbering leading to an assert in llc (prior to the fix).

llvm-svn: 133113

llvm-svn: 133108

Add a new MVT::untyped.  This will be used in future work for modelling ISA features like register pairs and lists with "interesting" constraints (such as ARM NEON contiguous register lists or even-odd paired registers).  We need to be able to generate these instructions (often from intrinsics), but don't want to have to assign a legal type to them.  Instead, we'll use an "untyped" edge to bypass the type-checking and simply ensure that the register classes match.

llvm-svn: 133106

llvm-svn: 133083

Added a test case for handling physreg aliases during pre-RA-sched.

llvm-svn: 133063

llvm-svn: 133057

Enable the simplification of truncating-store after fixing the usage of
GetDemandBits (which must operate on the vector element type).

Fix the a usage of getZeroExtendInReg which must also be done on scalar types.

llvm-svn: 133052

converted to add x,x if x is a undef.  add undef, undef does not guarantee
that the resulting low order bit is zero.
Fixes <rdar://problem/9453156> and <rdar://problem/9487392>.

llvm-svn: 133022

llvm-svn: 133007

Dan noted that this would work on the case shown on the commit message. I think
the case that was failing was a bb ending with a redundant conditional jump:

...
jne foo

foo:
...

I was unable to find any such case in the tests or in a debug build of clang,
so I will revert this part of the patch and watch the bots.

llvm-svn: 133004

llvm-svn: 132995

llvm-svn: 132988

Add a testcase for checking the integer-promotion of many different vector
types (with power of two types such as 8,16,32 .. 512).

Fix a bug in the integer promotion of bitcast nodes. Enable integer expanding
only if the target of the conversion is an integer (when the type action is
scalarize).

Add handling to the legalization of vector load/store in cases where the saved
vector is integer-promoted.

llvm-svn: 132985

llvm-svn: 132984

AnalyzeBranch.

llvm-svn: 132981

or instruction cache access. Update the targets to match it and also teach
autoupgrade.

llvm-svn: 132976

sharp all or nothing transition when one extra predecessor was added. Now
we still test first ones for merging.

llvm-svn: 132974

only if the number of packed elements is a power of two.
Bug found in Duncan's testcase.

llvm-svn: 132923

In particular, don't spill dirty registers only to satisfy a hint. It is
not worth it.

The attached test case provides an example where the fast allocator
would spill a register when other registers are available.

llvm-svn: 132900

llvm-svn: 132899

having.

llvm-svn: 132898

types such as i33 were rounded to i32. Originated from Duncan's testcase.

llvm-svn: 132893

Instead of scalarizing, and doing an element-by-element truncat, use vector
truncate.
Add support for scalarization of vectors:  i8 -> <1 x i1> (from Duncan's
testcase).

llvm-svn: 132892

Add a triple to the tests.

llvm-svn: 132885

llvm-svn: 132883

we try to branch to them.

Before we were creating successor lists with duplicated entries. Fixing that
found a bug in isBlockOnlyReachableByFallthrough that would causes it to
return the wrong answer for

-----------
...
jne foo
jmp bar

foo:
----------

llvm-svn: 132882

llvm-svn: 132872

llvm-svn: 132871

llvm-svn: 132863

llvm-svn: 132857

comment on their meaning.

llvm-svn: 132854

llvm-svn: 132853

llvm-svn: 132852

Thanks Bob Wilson for noticing it!

llvm-svn: 132851

and definitions when emitting global variables.  This was causing global 
declarations to be emitted as if they were definitions.
Fixes <rdar://problem/9429892>.

llvm-svn: 132825

llvm-svn: 132822

llvm-svn: 132821