stuff to emit optimal nops in the right places.

llvm-svn: 97233

present in the module.

llvm-svn: 97232

llvm-svn: 97231

llvm-svn: 97230

llvm-svn: 97229

llvm-svn: 97228

llvm-svn: 97227

Previously LoopStrengthReduce would sometimes be unable to find
a legal formula, causing an assertion failure.

llvm-svn: 97226

Use this information to find the returned value and bind it to CallExpr in
ProcessCallExit.
And there is no need to remove dead bindings in ProcessCallExit, because
a. it would clean up the return value bound to CallExpr
b. we still would do it in the next ProcessStmt(), where we would not misclean
   up the return value.

llvm-svn: 97225

fix, just trying to get the build bots happy again.

llvm-svn: 97223

llvm-svn: 97222

propagating error conditions out of the various annotate-me-a-snowflake
routines.  Generally (but not universally) removes redundant diagnostics
as well as, you know, not crashing on bad code.  On the other hand,
I have just signed myself up to fix fiddly parser errors for the next
week.  Again.

llvm-svn: 97221

llvm-svn: 97220

llvm-svn: 97219

gross little neighbor merging implementation.  This one has
the benefit of not violating the ordering of patterns, so it
generates code that passes tests again.

llvm-svn: 97218

llvm-svn: 97217

llvm-svn: 97216

current design.  This generates a matcher that successfully
runs, but it turns out that the factoring we're doing violates
the ordering of patterns, so we end up matching (e.g.) movups
where we want movaps.  This won't due, but I'll address this in
a follow on patch.  It's nice to not be on by default yet! :)

llvm-svn: 97215

that we never return a tombstone value, which (thankfully) triggers an
assert in densemap.

llvm-svn: 97214

object construction. There is no provision to change them when the 
code for a function generated. 
So we have to change these names while printing assembly.

llvm-svn: 97213

and restore the entire matcher stack by value.  This is because children
we're testing could do moveparent or other things besides just 
scribbling on additions to the stack.

llvm-svn: 97212

llvm-svn: 97211

instantiation so long as that explicit specialization was declared
previously. Fixes PR6160.

llvm-svn: 97210

how we find the operator delete that matches withe operator new we
found in a C++ new-expression.

This will also need CodeGen support. On a happy note, we're now a
"nans" away from building tramp3d-v4.

llvm-svn: 97209

llvm-svn: 97208

llvm-svn: 97207

llvm-svn: 97206

attributes. Fixes radar 7214439.

llvm-svn: 97203

llvm-svn: 97202

llvm-svn: 97201

llvm-svn: 97200

llvm-svn: 97199

the most users.

llvm-svn: 97198

the ABI-computation interface.  Fixes <rdar://problem/7691046>.

llvm-svn: 97197

the alignment requirement, if it no longer makes the TType base offset overflow
into extra bytes, then we need to pad to those bytes ourselves.

llvm-svn: 97196

used when we instantiate C++ new expressions, delete expressions, and
object-construction expressions. Fixes PR6424, although we can't test
all of it until we finish implementing lookup of "operator delete" for
new expressions (!).

llvm-svn: 97195

llvm-svn: 97193

llvm-svn: 97192

llvm-svn: 97186

to mark the constructor as referenced. Fixes the narrow issue reported
in PR6424, but there are a few other places that I'll fix before
closing out that PR.

llvm-svn: 97185