Affect on SD scheduling and postRA scheduling:
Printing the DAG will display the nodes in top-down topological order.
This matches the order within the MBB and makes my life much easier in general.

Affect on misched:
We don't need to track virtual register uses at all. This is awesome.
I also intend to rely on the SUnit ID as a topo-sort index. So if A < B then we cannot have an edge B -> A.

llvm-svn: 151135

Make all pointers to TargetRegisterClass const since they are all pointers to static data that should not be modified.

llvm-svn: 151134

This makes RAFast 4% faster, and it gets rid of the dodgy DenseMap
iteration.

This also revealed that RAFast would sometimes dereference DenseMap
iterators after erasing other elements from the map. That does seem to
work in the current DenseMap implementation, but SparseSet doesn't allow
it.

llvm-svn: 151111

bundles. This method takes a bundle start and an MI being bundled, and makes
the intervals for the MI's operands appear to start/end on the bundle start.

Also fixes some minor cosmetic issues (whitespace, naming convention) in the
HMEditor code.

llvm-svn: 151099

Part of rdar://10493979 where it reduces by about .5% (10k)

llvm-svn: 151097

Passes after RegAlloc should be able to rely on MRI->getNumVirtRegs() == 0.
This makes sharing code for pre/postRA passes more robust.
Now, to check if a pass is running before the RA pipeline begins, use MRI->isSSA().
To check if a pass is running after the RA pipeline ends, use !MRI->getNumVirtRegs().

PEI resets virtual regs when it's done scavenging.

PTX will either have to provide its own PEI pass or assign physregs.

llvm-svn: 151032

llvm-svn: 151031

llvm-svn: 151006

ecx = mov eax
al  = mov ch
The second copy is not a nop because the sub-indices of ecx,ch is not the
same of that of eax/al.

Re-enabled machine-cp.
PR11940

llvm-svn: 151002

llvm-svn: 150957

flow changes have already hidden the bug. rdar://10893812

llvm-svn: 150949

llvm-svn: 150921

llvm-svn: 150918

llvm-svn: 150915

llvm-svn: 150914

llvm-svn: 150912

llvm-svn: 150910

Defer sanity checks on live intervals until after all have been updated. Hold (LiveInterval, LiveRange) pairs to update, rather than vregs.

llvm-svn: 150909

llvm-svn: 150851

llvm-svn: 150848

llvm-svn: 150842

llvm-svn: 150841

llvm-svn: 150840

MRI keeps track of which physregs have been used. Make sure it gets
updated with all the regmask-clobbered registers.

Delete the closePhysRegsUsed() function which isn't necessary.

llvm-svn: 150830

any changes.

Internally this adds a private inner class HMEditor, to LiveIntervals. HMEditor provides
an API for updating live intervals when code is moved or bundled.

llvm-svn: 150826

llvm-svn: 150820

This caused miscompilations on out-of-tree targets, and possibly i386 as
well.

I'll find some other way of hoisting %rip-relative loads from loops
containing calls.

llvm-svn: 150816

... and it's probably best to use the correct alignment, rather than just guessing that it's the same as the size.

llvm-svn: 150813

It turns out that putting an 8-byte symbol in a 4-byte section makes Solaris ld sulk.  GNU ld is perfectly happy with it, which is worrying for a whole other set of reasons...

Thanks to Anton, Duncan and Rafael for helping me track this down.
Pointy hat to Rafael for introducing the bug in the first place.

llvm-svn: 150811

llvm-svn: 150778

llvm-svn: 150773

llvm-svn: 150771

Re-enable 150652 and 150654 - Make FPSCR non-reserved, and make MachineCSE bail on reserved registers. This *should* be safe as of r150786.

llvm-svn: 150769

llvm-svn: 150768

Disable machine copy propagation for now. It's known to be buggy (PR11940) and introduces subtle miscompiles in many places.

llvm-svn: 150703

llvm-svn: 150670

Modify the algorithm when traversing the DAGCombiner's worklist to be O(log N) for all operations. This fixes a horrible worst case with lots of nodes where 99% of the time was being spent in std::remove.

llvm-svn: 150669

llvm-svn: 150655

llvm-svn: 150653

Don't attempt to move instructions with regmask operands. They are most
likely calls anyway.

llvm-svn: 150634