llvm-svn: 52241

llvm-svn: 52239

llvm-svn: 52238

supported since r33492.

llvm-svn: 52237

Pass -silence-passes to bugpoint in testcases, this makes two out of three bugpoint testcases work again.

llvm-svn: 52236

found, this ensures that messages like "Found gcc" end up on stdout where they
belong.

llvm-svn: 52235

when bugpoint is running passes in a child process.

llvm-svn: 52234

error that caused it to redirect stderr to stdout too often.

This fix is applied identically to the win32 code as well, but that is
untested.
--Thi line, and those below, will be ignored--

M    System/Unix/Program.inc
M    System/Win32/Program.inc

llvm-svn: 52233

llvm-svn: 52232

Otherwise, failing tests other than the last one will not be reported.

llvm-svn: 52231

functional changes. Win32 code is untested, but should work fine.

In the unix variant, rename RedirectFD to RedirectIO and let that function
handle empty and null paths instead of doing that in the caller 3 times. This
is the same as win32 already does it.

In the win32 variant, use Path::isEmpty() instead of checking the resulting
c_str() manually. This is the same as unix already does it.

llvm-svn: 52230

for a particular MVT, return false if the type
is illegal rather than barfing.

llvm-svn: 52229

llvm-svn: 52228

llvm-svn: 52227

llvm-svn: 52226

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