script. Only the testsuite project needs to know this information.

llvm-svn: 140220

In the disassembler C API, be careful not to confuse the comment streamer that the disassembler outputs annotations on with the streamer that the InstPrinter will print them on.

llvm-svn: 140217

here anymore and has been migrated to the test-suite project.

llvm-svn: 140216

llvm-svn: 140214

llvm-svn: 140213

Make sure IPSCCP never marks a tracked call as overdefined in SCCPSolver::ResolvedUndefsIn.  If we do, we can end up in a situation where a function is resolved to return a constant, but the caller is marked overdefined, which confuses the code later.

<rdar://problem/9956541> (again).

llvm-svn: 140210

subvector inserts and extracts. Initial patch by Rackover, Zvi with
some tweak done by me.

llvm-svn: 140204

llvm-svn: 140203

It happens (for example) when you want to have a dependency on the .so
with the specific version, like liblzma.so.1.0.0 or
libcrypto.so.0.9.8.

llvm-svn: 140201

llvm-svn: 140199

Though I think it may be obsolete with the loop extract changes. And I couldn't
get the old version of LLVM to compile so that I could reduce this testcase.

llvm-svn: 140197

Some passes require breaking critical edges before they're called. Don't
segfault because of that.

llvm-svn: 140196

Place the check for an exit landing pad where it will be run on both code paths through the if-then-else.

llvm-svn: 140195

llvm-svn: 140194

The landing pad must accompany the invoke when it's extracted. However, if it
does, then the loop isn't properly extracted. I.e., the resulting extraction has
a loop in it. The extracted function is then extracted, etc. resulting in an
infinite loop.

llvm-svn: 140193

This was only needed to locate llvm-gcc's installation directory when clang
falls back to run llvm-gcc for i386 kexts.  As of clang svn r140187, we're
now just searching paths with several different Darwin versions on either
side of the current version, so this is no longer needed.

llvm-svn: 140188

llvm-svn: 140186

This fixes PR10963. Thanks to Benjamin for finding the wrong tablegen
declaration.

llvm-svn: 140184

llvm-svn: 140183

Fix a bug introduced during refactoring a couple of months ago. Cortex-M3 does not support Thumb2 dsp instructions. rdar://10152911.

llvm-svn: 140181

llvm-svn: 140178

llvm-svn: 140177

llvm-svn: 140176

extract its associated landing pad block as well. However, that landing pad
block may have more than one predecessor. So split the landing pad block so that
individual landing pads have only one predecessor.

This type of transformation may produce a false positive with bugpoint.

llvm-svn: 140173

llvm-svn: 140172

llvm-svn: 140169

llvm-svn: 140168

llvm-svn: 140167

llvm-svn: 140166

llvm-svn: 140164

llvm-svn: 140163

No functionality change. The hook makes it explicit which patterns
require "special" handling. i.e. it self-documents tblgen
deficiencies. I plan to add verification in ExpandISelPseudos and
Thumb2SizeReduce to catch any missing hasPostISelHooks. Otherwise it's
too fragile.

llvm-svn: 140160

llvm-svn: 140158

llvm-svn: 140157

llvm-svn: 140156

llvm-svn: 140154

llvm-svn: 140153

llvm-svn: 140152

GCOVLines is always accessed through a StringMap where the key is FileName.

llvm-svn: 140151

There is no need to write a local utility routine to find subprogram info if the utility routine is already available in DebugInfo.

llvm-svn: 140145