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

switch from this:

  if (TimePassesIsEnabled) {
    NamedRegionTimer T(Name, GroupName);
    do_something();
  } else {
    do_something(); // duplicate the code, this time without a timer!
  }

to this:

  {
    NamedRegionTimer T(Name, GroupName, TimePassesIsEnabled);
    do_something();
  }

llvm-svn: 106285

the old one.

llvm-svn: 106284

Don't replace the old DbgInfo with a new one when clear() on the
old one is sufficient.

llvm-svn: 106283

SDNode *, since it doesn't care about the ResNo value.

llvm-svn: 106282

is more consistent with the ConstantInt API.

llvm-svn: 106281

llvm-svn: 106280

llvm-svn: 106279

llvm-svn: 106278

llvm-svn: 106277

Also, test that static members with default visibility in a struct have the
right mangling.

llvm-svn: 106276

- Precision toStrings shouldn't print a dot when they have no value.
- Length of char length modifier is now returned correctly.
- Added several fixit tests.

Note: fixit tests are currently broken due to a bug in HighlightRange. Marking as XFAIL for now.

M    test/Sema/format-strings-fixit.c
M    include/clang/Analysis/Analyses/PrintfFormatString.h
M    lib/Analysis/PrintfFormatString.cpp

llvm-svn: 106275

llvm-svn: 106274

llvm-svn: 106273

llvm-svn: 106272

Fix from Russel Power in PR7284.

llvm-svn: 106271

llvm-svn: 106269

llvm-svn: 106268

This fixes PR7333.

llvm-svn: 106267

to track a node over CSE events. This fixes PR7368.

llvm-svn: 106266

Move the "status" command to "process status" since that's where it belongs.  Also make it print "running" if invoked 
when the current process is running.

llvm-svn: 106265

llvm-svn: 106264

which is faster, simpler, and less surprising.

llvm-svn: 106263