CALLSEQ_BEGIN & CALLSEQ_END.

llvm-svn: 52225

For now, avoid generating FP select instructions in order to speculatively execute integer arithmetic instructions. FP selects are more likely to be expensive (even compared to branch on fcmp). This is not a wonderful solution but I rather err on the side of conservative.

This fixes the heapsort performance regressions.

llvm-svn: 52224

Avoid duplicating loop header which leads to unnatural loops (and just seem like general badness to me, likely to cause code explosion).
Patch by Florian Brandner.

llvm-svn: 52223

llvm-svn: 52222

llvm-svn: 52221

llvm-svn: 52218

useless insert-extract chains, similar to how it folds them for vectors.

Add a testcase for this.

llvm-svn: 52217

llvm-svn: 52216

llvm-svn: 52215

maps can be deleted.  This happens when RAUW
replaces a node N with another equivalent node
E, deleting the first node.  Solve this by
adding (N, E) to ReplacedNodes, which is already
used to remap nodes to replacements.  This means
that deleted nodes are being allowed in maps,
which can be delicate: the memory may be reused
for a new node which might get confused with the
old deleted node pointer hanging around in the
maps, so detect this and flush out maps if it
occurs (ExpungeNode).  The expunging operation
is expensive, however it never occurs during
a llvm-gcc bootstrap or anywhere in the nightly
testsuite.  It occurs three times in "make check":
Alpha/illegal-element-type.ll,
PowerPC/illegal-element-type.ll and
X86/mmx-shift.ll.  If expunging proves to be too
expensive then there are other more complicated
ways of solving the problem.
In the normal case this patch adds the overhead
of a few more map lookups, which is hopefully
negligable.

llvm-svn: 52214

If this doesn't work, I'll write a configure test.

llvm-svn: 52213

llvm-svn: 52212

llvm-svn: 52210

isn't guaranteed to exist. This fixes a crash with conflicting typedefs
coming from stdin.

This also fixes the crash in PR2406, but doesn't completely fix the 
issue; it appears there's something strange about the physical location 
for the definition of int64_t in stdlib.h.

llvm-svn: 52209

llvm-svn: 52208

llvm-svn: 52207

llvm-svn: 52206

llvm-svn: 52205

llvm-svn: 52204

llvm-svn: 52203

llvm-svn: 52202

llvm-svn: 52201

llvm-svn: 52200

llvm-svn: 52199

llvm-svn: 52198

llvm-svn: 52197

llvm-svn: 52196

llvm-svn: 52195

llvm-svn: 52194

llvm-svn: 52193

llvm-svn: 52191

llvm-svn: 52190

llvm-svn: 52189

The test still fails because an expected symbol is not
present, and I don't see why it should be.

llvm-svn: 52188

Warnings are legitimate.

llvm-svn: 52187

harness to fail the tests.  The warning all appear
legitimate.

llvm-svn: 52186

llvm-svn: 52185

This fixes 2 testcases.

llvm-svn: 52184

variable expansions involving the $ character.

This fixes 4 tests that were not running properly before.

llvm-svn: 52183

cases quoting of <{ didn't work out, so I changed the grep to check for }>
instead.

This fixes 7 testcases that were not properly running before.

llvm-svn: 52182