llvm-svn: 114468

Add a warning if no command was attached to the breakpoint.
Update the help slightly.

llvm-svn: 114467

@expectedFailure as of r114384.

llvm-svn: 114466

llvm-svn: 114465

I think I've audited all uses, so it should be dependable for address spaces,
and the pointer+offset info should also be accurate when there.

llvm-svn: 114464

llvm-svn: 114463

llvm-svn: 114461

(sbbl x, x) sets the registers to 0 or ~0.  Combined with two's complement arithmetic, we can fold
the intermediate AND and the ADD into a single SUB.

This fixes <rdar://problem/8449754>.

llvm-svn: 114460

llvm-svn: 114459

with missing LHS. radar 8453812. Executable test is checked 
into llvm test suite.

llvm-svn: 114457

For ObjCPropertyDecls in class extensions, use the class extension as the lexical DeclContext for newly created
ObjCMethodDecls.  Further, use the location of the new property declaration as the location of new ObjCMethodDecls
(if they didn't previously exist).

This fixes more of the issues reported in <rdar://problem/7410145>.

llvm-svn: 114456

llvm-svn: 114455

and store intrinsics are represented with MemIntrinsicSDNodes.

llvm-svn: 114454

llvm-svn: 114453

MachinePointerInfo around more.

llvm-svn: 114452

llvm-svn: 114451

llvm-svn: 114450

with an indexed load/store that has an offset in the index.

llvm-svn: 114449

instead of calling lower_bound or upper_bound directly.

This cleans up the search logic a bit because {lower,upper}_bound compare
LR->start by default, and it is usually simpler to search LR->end.

Funnelling all searches through one function also makes it possible to replace
the search algorithm with something faster than binary search.

llvm-svn: 114448

llvm-svn: 114447

SelectionDAG::getExtLoad overload, and eliminate it.

llvm-svn: 114446

llvm-svn: 114445

llvm-svn: 114444

getLoad overloads.

llvm-svn: 114443

with SVOffset computation.

llvm-svn: 114442

class template) and are in a context where we can have a value.

llvm-svn: 114441

llvm-svn: 114440

llvm-svn: 114439

llvm-svn: 114438

llvm-svn: 114437

no functionality change (step #1)

llvm-svn: 114436

llvm-svn: 114435

llvm-svn: 114434

llvm-svn: 114433

llvm-svn: 114432

llvm-svn: 114431

I am unable to write a test for this case, help is solicited, though...
What I did is to tickle the code in the debugger and verify that we do the right thing.

llvm-svn: 114430

Added an additional PBQP problem builder which adds coalescing costs (both between pairs of virtuals, and between virtuals and physicals).

llvm-svn: 114429

into OptimizeCompareInstr.
This necessitates the passing of CmpValue around,
so widen the virtual functions to accomodate.

No functionality changes.

llvm-svn: 114428

llvm-svn: 114427