Local live range splitting is better driven by interference. This code was just
guessing.

llvm-svn: 126799

This is a waste of time since we already know how to evict all interferences
which is a better approach anyway.

llvm-svn: 126798

Patch by Erik Olofsson!

llvm-svn: 126796

llvm-svn: 126794

Today, the language front ends produces llvm.dbg.* intrinsics, used to encode arguments' debug info, in order any way, most of the times. However, if a front end mix-n-matches llvm.dbg.declare and llvm.dbg.value intrinsics to encode debug info for arguments then code generator needs a way to find argument order.

Use 8 bits from line number field to keep track of argument ordering while encoding debug info for an argument. That leaves 24 bit for line no, DebugLoc also allocates 24 bit for line numbers. If a function has more than 255 arguments then rest of the arguments will be ordered by llvm.dbg.* intrinsics' ordering in IR.

llvm-svn: 126793

addressing code. On 403.gcc this almost halves CodeGenPrepare time and reduces
total llc time by 9.5%. Unfortunately, getNumUses() is still the hottest function
in llc.

llvm-svn: 126782

This effectively disables the 'turbo' functionality of the greedy register
allocator where all new live ranges created by splitting would be reconsidered
as if they were originals.

There are two reasons for doing this, 1. It guarantees that the algorithm
terminates. Early versions were prone to infinite looping in certain corner
cases. 2. It is a 2x speedup. We can skip a lot of unnecessary interference
checks that won't lead to good splitting anyway.

The problem is that region splitting only gets one shot, so it should probably
be changed to target multiple physical registers at once.

Local live range splitting is still 'turbo' enabled. It only accounts for a
small fraction of compile time, so it is probably not necessary to do anything
about that.

llvm-svn: 126781

llvm-svn: 126780

llvm-svn: 126773

llvm-svn: 126759

in alphabetical order.

llvm-svn: 126745

intersection of the LHS and RHS ConstantRanges and return "false" when
the range is empty.

This simplifies some code and catches some extra cases.

llvm-svn: 126744

more work to do here, "icmp ult (urem X, 10), 11" doesn't optimize away yet.
Fixes example 3 from PR9343!

llvm-svn: 126741

llvm-svn: 126733

llvm-svn: 126731

shift.

   16-bit: imm6<5:3> = '001', 8 - <imm> is encded in imm6<2:0>
   32-bit: imm6<5:4> = '01',16 - <imm> is encded in imm6<3:0>
   64-bit: imm6<5> = '1', 32 - <imm> is encded in imm6<4:0>

llvm-svn: 126723

llvm-svn: 126720

llvm-svn: 126719

llvm-svn: 126717

llvm-svn: 126715

llvm-svn: 126714

llvm-svn: 126694

llvm-svn: 126689

llvm-svn: 126687

Make all static functions become static class methods. Move shared (duplicated) functions to new MCELF class.

llvm-svn: 126686

llvm-svn: 126684

llvm-svn: 126683

llvm-svn: 126682

llvm-svn: 126671

only existed as the result of a misunderstanding.

llvm-svn: 126669

was started for in the foreseeable future.

llvm-svn: 126668

[AVX] Add decode support for VUNPCKLPS/D instructions, both 128-bit
      and 256-bit forms.  Because the number of elements in a vector
      does not determine the vector type (4 elements could be v4f32 or
      v4f64), pass the full type of the vector to decode routines.

llvm-svn: 126664

needed two predicate operands before the imm operand.

llvm-svn: 126662

llvm-svn: 126661

patch to the front-end.  Radar 7662569.

llvm-svn: 126655

The implemented algorithm is overly simplistic (just speculate all branches are
taken)- this is work in progress.

llvm-svn: 126651

Based on a patch by Alistair Lynn.

llvm-svn: 126647

llvm-svn: 126645

also have a zero when numerator = denominator. Reverts parts of r126635 and
r126637.

llvm-svn: 126644

PR9343.

llvm-svn: 126643