llvm-svn: 71010

For implicit decls like "self" and "_cmd" in ObjC, these decls
should not have a location.

llvm-svn: 70964

llvm-svn: 70953

llvm-svn: 70950

llvm-svn: 70937

shows up in -print-machineinstrs.  This doesn't appear to affect anything, but it was
weird for some DBG_LABELs to have DebugLocs but not all of them.

llvm-svn: 70921

llvm-svn: 70900

-Depend on DebugLocs for source line info.

(Comes with Regression-Be-Gone(tm))

llvm-svn: 70871

llvm-svn: 70821

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