llvm-svn: 106342

llvm-svn: 106340

llvm-svn: 106339

to use them instead of SourceRange.  CharSourceRange is just a SourceRange
plus a bool that indicates whether the range has the end character resolved
or whether the end location is the start of the end token.  While most of
the compiler wants to think of ranges that have ends that are the start of
the end token, the printf diagnostic stuff wants to highlight ranges within
tokens.

This is transparent to the diagnostic stuff.  To start taking advantage of
the new capabilities, you can do something like this:
  Diag(..) << CharSourceRange::getCharRange(Begin,End)

llvm-svn: 106338

llvm-svn: 106336

llvm-svn: 106335

instructions, but it doesn't really understand live ranges, so the first
INSERT_SUBREG uses an implicitly defined register.

Fix it in LiveVariableAnalysis by adding the <undef> flag.

llvm-svn: 106333

llvm-svn: 106330

<rdar://problem/8108088>.

llvm-svn: 106328

llvm-svn: 106327

llvm-svn: 106324

Teach iff-converter to properly count # of dups. It was not skipping over dbg_value's which resulted in non-duplicated instructions being deleted. rdar://8104384.

llvm-svn: 106323

(radar 8076356) - wip.

llvm-svn: 106322

entries used by llvm-gcc. *_[U]MIN and such can be added later if needed.

This enables the front ends to simplify handling of the atomic intrinsics by
removing the target-specific decision about which targets can handle the
intrinsics.

llvm-svn: 106321

list is completely empty, from Lasse Kärkkäinen! Fixes PR7413.

llvm-svn: 106320

(as suggested in radar 8104405).

llvm-svn: 106318

function to redeclarations of that function. Fixes PR7025.

llvm-svn: 106317

llvm-svn: 106314

limit on the offset that can be materialized without using the register
scavenger.

llvm-svn: 106312

llvm-svn: 106311

original basic block. This avoids trouble with examining
instructions in other basic blocks which haven't been
assigned registers yet.

llvm-svn: 106310

ARM tail calls.  Don't know if it works, but it
doesn't break Darwin.

llvm-svn: 106309

optimizations. There is still some nondeterminism remaining.

llvm-svn: 106306

The rule is simple: only inherit from a class list if they come
in the end, after the last multiclass.

llvm-svn: 106305

llvm-svn: 106304

ask the linker to take another look into some library or object. The case when
one might want to do this is when codegen introduces a new undefined reference.
The canonical example is libgcc.

llvm-svn: 106303

llvm-svn: 106302

llvm-svn: 106301

llvm-svn: 106300

basic tests.

This has been well tested on Darwin but not elsewhere.
It should work provided the linker correctly resolves
  B.W  <label in other function>
which it has not seen before, at least from llvm-based
compilers.  I'm leaving the arm-tail-calls switch in
until I see if there's any problems because of that;
it might need to be disabled for some environments.

llvm-svn: 106299

std::vector.

llvm-svn: 106298

llvm-svn: 106297

MachineRegisterInfo doesn't have to confusingly allocate an extra
entry.

llvm-svn: 106296

Not turning them on yet.

llvm-svn: 106295

llvm-svn: 106292

so when IfConverter::CopyAndPredicateBlock checks to see if it should ignore
an instruction because it is a branch, it should not check if the branch is
predicated.

This case (when IgnoreBr is true) is only relevant from IfConvertTriangle,
where new branches are inserted after the block has been copied and predicated.
If the original branch is not removed, we end up with multiple conditional
branches (possibly conflicting) at the end of the block.  Aside from any
immediate errors resulting from that, this confuses the AnalyzeBranch functions
so that the branches are not analyzable.  That in turn causes the IfConverter to
think that the "Simple" pattern can be applied, and things go downhill fast
because the "Simple" pattern does _not_ apply if the block can fall through.

This is pretty fragile.  If there are other degenerate cases where AnalyzeBranch
fails, but where the block may still fall through, the IfConverter should not
perform its "Simple" if-conversion.  But, I don't know how to do that with the
current AnalyzeBranch interface, so for now, the best thing seems to be to
avoid creating branches that AnalyzeBranch cannot handle.

Evan, please review!

llvm-svn: 106291

does for {flags}. If we create virtual registers of the CCR class, RegAllocFast
may try to spill them, and we can't do that.

llvm-svn: 106289

llvm-svn: 106288

llvm-svn: 106287

llvm-svn: 106286