TwoAddressInstructionPass should annotate instructions with <undef>
flags when it lower REG_SEQUENCE instructions.  LiveIntervals should not
be in the business of modifying code (except for kill flags, perhaps).

llvm-svn: 141187

llvm-svn: 141184

llvm-svn: 141183

llvm-svn: 141182

llvm-svn: 141181

llvm-svn: 141180

creation, so that only a single Clang instance will rebuild a given
module at once (and the others will wait).

We still don't clean up the lock files when we crash, which is a
rather unfortunate problem. I'll handle that next, and there is
certainly a *lot* of room for further improvements.

llvm-svn: 141179

llvm-svn: 141178

branch "br i1 %x, label %if_true, label %if_false" then it replaces
"%x" with "true" in places only reachable via the %if_true arm, and
with "false" in places only reachable via the %if_false arm.  Except
that actually it doesn't: if value numbering shows that %y is equal
to %x then, yes, %y will be turned into true/false in this way, but
any occurrences of %x itself are not transformed.  Fix this.  What's
more, it's often the case that %x is an equality comparison such as
"%x = icmp eq %A, 0", in which case every occurrence of %A that is
only reachable via the %if_true arm can be replaced with 0.  Implement
this and a few other variations on this theme.  This reduces the number
of lines of LLVM IR in "GCC as one big file" by 0.2%.  It has a bigger
impact on Ada code, typically reducing the number of lines of bitcode
by around 0.4% by removing repeated compiler generated checks.  Passes
the LLVM nightly testsuite and the Ada ACATS testsuite.

llvm-svn: 141177

it's OK for the false/true destination to have multiple
predecessors as long as the extra ones are dominated by
the branch destination.

llvm-svn: 141176

llvm-svn: 141174

llvm-svn: 141173

it returns false, at least as far as I could tell by reading the code.

llvm-svn: 141172

llvm-svn: 141171

C-style and functional casts are built in SemaCXXCast.cpp.
Introduce a helper class to encapsulate most of the random
state being passed around, at least one level down.

llvm-svn: 141170

llvm-svn: 141169

llvm-svn: 141168

have noticed this previously, sorry.

llvm-svn: 141167

llvm-svn: 141166

llvm-svn: 141165

I noticed during self-review that my previous checkin disabled some
analysis. Even with the reenabled analysis the test case runs in about
5ms. Without the fix, it will take several minutes at least.

llvm-svn: 141164

llvm-svn: 141163

llvm-svn: 141162

Note to compiler writers: never recurse on multiple instruction
operands without memoization.
Fixes rdar://10187945. Was taking 45s, now taking 5ms.

llvm-svn: 141161

using the mutex.

llvm-svn: 141160

"versions". Currently, these are just dropped on the floor, A concrete
version number will always win out.

llvm-svn: 141159

llvm-svn: 141158

llvm-svn: 141157

llvm-svn: 141156

Record the registers used and defined by a call in Filler::insertDefsUses.

llvm-svn: 141154

llvm-svn: 141152

filled the last delay slot visited.

llvm-svn: 141151

Filler::findDelayInstr.

llvm-svn: 141150

instructions (instructions that are not NOP).

llvm-svn: 141149

I->getDesc().hasDelaySlot() does.

llvm-svn: 141148

not have to be set.

llvm-svn: 141147

llvm-svn: 141146

this saga. Teach the driver to detect a GCC installed along side Clang
using the existing InstalledDir support in the Clang driver. This makes
a lot of Clang's behavior more automatic when it is installed along side
GCC.

Also include the first test cases (more to come, honest) which test both
the install directory behavior, and the version sorting behavior to show
that we're actually searching for the best candidate GCC installation
now.

llvm-svn: 141145

when newly created threads were subsequently stopped due to breakpoint hit.
The stop-hook mechanism delegates to CommandInterpreter::HandleCommands() to
execuet the commands.  Make sure the execution context is switched only once
at the beginning of HandleCommands() only and don't update the context while looping
on each individual command to be executed.

rdar://problem/10228156

llvm-svn: 141144

the value exceeds that number.

llvm-svn: 141143