This is done by pushing physical register definitions close to their
use, which happens to handle flag definitions if they're not glued to
the branch. This seems to be generally a good thing though, so I
didn't need to add a target hook yet.

The primary motivation is to generate code closer to what people
expect and rule out missed opportunity from enabling macro-op
fusion. As a side benefit, we get several 2-5% gains on x86
benchmarks. There is one regression:
SingleSource/Benchmarks/Shootout/lists slows down be -10%. But this is
an independent scheduler bug that will be tracked separately.
See rdar://problem/9283108.

Incidentally, pre-RA scheduling is only half the solution. Fixing the
later passes is tracked by:
<rdar://problem/8932804> [pre-RA-sched] on x86, attempt to schedule CMP/TEST adjacent with condition jump

Fixes:
<rdar://problem/9262453> Scheduler unnecessary break of cmp/jump fusion

llvm-svn: 129508

llvm-svn: 129503

During post-legalization DAG combining, be careful to only create shifts where the RHS is of the legal type for the new operation.

llvm-svn: 129484

Remove extra bytes that were added for gdb.  We do not have good poiner to understand actual reason behind this fixme. Spot checking suggest that newer gdb does not need this.

llvm-svn: 129461

llvm-svn: 129442

Additional fixes:
Do something reasonable for subtargets with generic
itineraries by handle node latency the same as for an empty
itinerary. Now nodes default to unit latency unless an itinerary
explicitly specifies a zero cycle stage or it is a TokenFactor chain.

Original fixes:
UnitsSharePred was a source of randomness in the scheduler: node
priority depended on the queue data structure. I rewrote the recent
VRegCycle heuristics to completely replace the old heuristic without
any randomness. To make the ndoe latency adjustments work, I also
needed to do something a little more reasonable with TokenFactor. I
gave it zero latency to its consumers and always schedule it as low as
possible.

llvm-svn: 129421

llvm-svn: 129417

registers for fast allocation.

Fixes rdar://9207598

llvm-svn: 129408

llvm-svn: 129407

llvm-svn: 129406

llvm-svn: 129405

This mechanical patch moves type handling into CompileUnit from DwarfDebug. In case of multiple compile unit in one object file, each compile unit is responsible for its own set of type entries anyway. This refactoring makes this obvious.

llvm-svn: 129402

llvm-svn: 129400

Use a Bitvector instead, we didn't need the smaller memory footprint anyway.
This makes the greedy register allocator 10% faster.

llvm-svn: 129390

llvm-svn: 129385

UnitsSharePred was a source of randomness in the scheduler: node
priority depended on the queue data structure. I rewrote the recent
VRegCycle heuristics to completely replace the old heuristic without
any randomness. To make these heuristic adjustments to node latency work,
I also needed to do something a little more reasonable with TokenFactor. I
gave it zero latency to its consumers and always schedule it as low as
possible.

llvm-svn: 129383

This merges the behavior of splitSingleBlocks into splitAroundRegion, so the
RS_Region and RS_Block register stages can be coalesced. That means the leftover
intervals after region splitting go directly to spilling instead of a second
pass of per-block splitting.

llvm-svn: 129379

This makes it possible to target multiple registers in one pass.

llvm-svn: 129374

llvm-svn: 129373

llvm-svn: 129368

llvm-svn: 129367

llvm-svn: 129334

when compiling many small functions.

llvm-svn: 129321

mean that it has to be ConstantArray of ConstantStruct. We might have
ConstantAggregateZero, at either level, so don't crash on that.

Also, semi-deprecate the sentinal value. The linker isn't aware of sentinals so
we end up with the two lists appended, each with their "sentinals" on them.
Different parts of LLVM treated sentinals differently, so make them all just
ignore the single entry and continue on with the rest of the list.

llvm-svn: 129307

weight limit has been exceeded.

llvm-svn: 129305

the 'unwind' instruction. However, later on that instruction was converted into
a jump to the basic block it was located in, causing an infinite loop when we
get there.

It turns out, we get there if the _Unwind_Resume_or_Rethrow call returns (which
it's not supposed to do). It returns if it cannot find a place to unwind
to. Thus we would get what appears to be a "hang" when in reality it's just that
the EH couldn't be propagated further along.

Instead of infinitely looping (or calling `unwind', which none of our back-ends
support (it's lowered into nothing...)), call the @llvm.trap() intrinsic
instead. This may not conform to specific rules of a particular language, but
it's rather better than infinitely looping.

<rdar://problem/9175843&9233582>

llvm-svn: 129302

Look pass copies when determining whether hoisting would end up inserting more copies. rdar://9266679

llvm-svn: 129297

LiveIntervals::findLiveInMBBs has to do a full binary search for each segment.

llvm-svn: 129292

llvm-svn: 129287

Both coalescing and register allocation already check aliases for interference,
so these extra segments are only slowing us down.

This speeds up both linear scan and the greedy register allocator.

llvm-svn: 129283

This particularly helps with the initial transfer of fixed intervals.

llvm-svn: 129277

llvm-svn: 129276

In particular, don't repeatedly recompute the PIC base live range after rematerialization.

llvm-svn: 129275

llvm-svn: 129271

Switch lowering probably shouldn't be using FP for this.  This resolves PR9581.

llvm-svn: 129199

It is common for large live ranges to have few basic blocks with register uses
and many live-through blocks without any uses. This approach grows the Hopfield
network incrementally around the use blocks, completely avoiding checking
interference for some through blocks.

llvm-svn: 129188

This doesn't require seeking in the live interval union, so it is very cheap.

llvm-svn: 129187

with undef arguments.

llvm-svn: 129185

Simplify array bound checks and clarify comments.  One element array can have same non-zero number as lower bound as well as upper bound.

llvm-svn: 129170

If lower bound is more then upper bound then consider it is an unbounded array.
An array is unbounded if non-zero lower bound is same as upper bound.
If lower bound and upper bound are zero than array has one element.

llvm-svn: 129156