The stack slots which share the same stack slot after coloring can, but do not have to, use the same register. In fact, they each may have different register class requirements.

llvm-svn: 70815

llvm-svn: 70811

-Depend on DebugLocs for source line info.

llvm-svn: 70803

llvm-svn: 70792

In some rare cases, the register allocator can spill registers but end up not utilizing registers at all. The fundamental problem is linearscan's backtracking can end up freeing more than one allocated registers. However,  reloads and restores might be folded into uses / defs and freed registers might not be used at all.

VirtRegMap keeps track of allocations so it knows what's not used. As a horrible hack, the stack coloring can color spill slots with *free* registers. That is, it replace reload and spills with copies from and to the free register. It unfold instructions that load and store the spill slot and replace them with register using variants.

Not yet enabled. This is part 1. More coming.

llvm-svn: 70787

llvm-svn: 70770

llvm-svn: 70764

llvm-svn: 70750

llvm-svn: 70749

-Create DebugLocs without the need to have a DwarfWriter around

llvm-svn: 70682

Changes to take advantage of this will come later.

llvm-svn: 70560

llvm-svn: 70539

llvm-svn: 70537

llvm-svn: 70534

llvm-svn: 70533

llvm-svn: 70524

-Replace DebugLocTuple's Source ID with CompileUnit's GlobalVariable*
-Remove DwarfWriter::getOrCreateSourceID
-Make necessary changes for the above (fix callsites, etc.)

llvm-svn: 70520

llvm-svn: 70513

Add a smarter heuristic to determine when to coalesce a virtual register with a physical one. More specifically, it avoid tying a virtual register in the loop with a physical register defined / used outside the loop. When it determines it's not profitable, it will use the physical register as the allocation preference instead.

This is *not* turned on by default. Testing indicates this is just as likely to pessimize code. The main issue seems to be allocation preference doesn't work effectively. That will change once I've taught register allocator "swapping".

llvm-svn: 70503

class.

llvm-svn: 70488

memory operands otherwise the writebacks get lost when the inline asm 
doesn't otherwise have side effects.  This fixes rdar://6839427, though
clang really shouldn't generate these anymore.

llvm-svn: 70455

which better identifies what the optimization is doing. And is more flexible for
future uses.

llvm-svn: 70440

llvm-svn: 70425

llvm-svn: 70408

llvm-svn: 70391

spillPhysRegAroundRegDefsUses() may have invalidated iterators stored in fixed_ IntervalPtrs. Reset them.

llvm-svn: 70378

llvm-svn: 70372

llvm-svn: 70366

anything larger than 64-bits, avoiding a crash.  This should
really be fixed to use APInts, though type legalization happens
to help us out and we get good code on the attached testcase at
least.

This fixes rdar://6836460

llvm-svn: 70360

Determine allocation 'preference' with right register class. I haven't seen this changing codegen so no test case.

llvm-svn: 70351

Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want to
use the old behavior, the flag is -O0. This change allows for finer-grained
control over which optimizations are run at different -O levels.

Most of this work was pretty mechanical. The majority of the fixes came from
verifying that a "fast" variable wasn't used anymore. The JIT still uses a
"Fast" flag. I'll change the JIT with a follow-up patch.

llvm-svn: 70343

llvm-svn: 70309

If the physical register does not belong to the virtual register's regclass,
don't coalesce. The physical register could be an invalid operand for an
instruction using the vreg.

The regclass matching is done after determining the actual subregisters being copied.

llvm-svn: 70298

llvm-svn: 70297

Also make the method non-asserting. It will return NULL when given an invalid subreg index.

The method is needed by an upcoming patch.

llvm-svn: 70296

llvm-svn: 70291

llvm-svn: 70279

llvm-svn: 70275

use the old behavior, the flag is -O0. This change allows for finer-grained
control over which optimizations are run at different -O levels.

Most of this work was pretty mechanical. The majority of the fixes came from
verifying that a "fast" variable wasn't used anymore. The JIT still uses a
"Fast" flag. I'm not 100% sure if it's necessary to change it there...

llvm-svn: 70270

llvm-svn: 70245