llvm-svn: 52267

Teach the spiller to commute instructions in order to fold a reload. This hits 410 times on 444.namd and 122 times on 252.eon.

llvm-svn: 52266

when trying to sink stores.

llvm-svn: 52259

for it to generate use-before-def IR, such as in this testcase.

llvm-svn: 52258

structure checks are incorrect if the blocks aren't distinct.
Fixes PR2435.

llvm-svn: 52257

wrong for volatile loads and stores.  In fact this
is almost all of them!  There are three types of
problems: (1) it is wrong to change the width of
a volatile memory access.  These may be used to
do memory mapped i/o, in which case a load can have
an effect even if the result is not used.  Consider
loading an i32 but only using the lower 8 bits.  It
is wrong to change this into a load of an i8, because
you are no longer tickling the other three bytes.  It
is also unwise to make a load/store wider.  For
example, changing an i16 load into an i32 load is
wrong no matter how aligned things are, since the
fact of loading an additional 2 bytes can have
i/o side-effects.  (2) it is wrong to change the
number of volatile load/stores: they may be counted
by the hardware.  (3) it is wrong to change a volatile
load/store that requires one memory access into one
that requires several.  For example on x86-32, you
can store a double in one processor operation, but to
store an i64 requires two (two i32 stores).  In a
multi-threaded program you may want to bitcast an i64
to a double and store as a double because that will
occur atomically, and be indivisible to other threads.
So it would be wrong to convert the store-of-double
into a store of an i64, because this will become two
i32 stores - no longer atomic.  My policy here is
to say that the number of processor operations for
an illegal operation is undefined.  So it is alright
to change a store of an i64 (requires at least two
stores; but could be validly lowered to memcpy for
example) into a store of double (one processor op).
In short, if the new store is legal and has the same
size then I say that the transform is ok.  It would
also be possible to say that transforms are always
ok if before they were illegal, whether after they
are illegal or not, but that's more awkward to do
and I doubt it buys us anything much.
However this exposed an interesting thing - on x86-32
a store of i64 is considered legal!  That is because
operations are marked legal by default, regardless of
whether the type is legal or not.  In some ways this
is clever: before type legalization this means that
operations on illegal types are considered legal;
after type legalization there are no illegal types
so now operations are only legal if they really are.
But I consider this to be too cunning for mere mortals.
Better to do things explicitly by testing AfterLegalize.
So I have changed things so that operations with illegal
types are considered illegal - indeed they can never
map to a machine operation.  However this means that
the DAG combiner is more conservative because before
it was "accidentally" performing transforms where the
type was illegal because the operation was nonetheless
marked legal.  So in a few such places I added a check
on AfterLegalize, which I suppose was actually just
forgotten before.  This causes the DAG combiner to do
slightly more than it used to, which resulted in the X86
backend blowing up because it got a slightly surprising
node it wasn't expecting, so I tweaked it.

llvm-svn: 52254

llvm-svn: 52251

with code that was expecting different bit widths for different values.

Make getTruncateOrZeroExtend a method on ScalarEvolution, and use it.

llvm-svn: 52248

llvm-svn: 52247

llvm-svn: 52246

Do not speculatively execute an instruction by hoisting it to its predecessor BB if any of its operands are defined but not used in BB. The transformation will prevent the operand from being sunk into the use block.

llvm-svn: 52244

llvm-svn: 52243

llvm-svn: 52242

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

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

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

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

Add a testcase for this.

llvm-svn: 52217

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: 52191

value, which is something that apparently isn't used much.

llvm-svn: 52158

types on functions, with adjustments so that it accepts both
new-style aggregate returns and old-style MRV returns, including those
with only a single member.

llvm-svn: 52157

llvm-svn: 52156

change for non-funky-sized integers.

llvm-svn: 52151

llvm-svn: 52150

llvm-svn: 52149

llvm-svn: 52147

llvm-svn: 52146

llvm-svn: 52144

of integer types.  Fix the isMask APInt method to
actually work (hopefully) rather than crashing
because it adds apints of different bitwidths.
It looks like isShiftedMask is also broken, but
I'm leaving that one to the APInt people (it is
not used anywhere).

llvm-svn: 52142

llvm-svn: 52139

llvm-svn: 52138

result of a weak function.

llvm-svn: 52137

function into a weak function, zap the weak function body so that the
strong one overrides it.  This fixes PR2410

llvm-svn: 52135

function bodies.  We now don't try to unify types or handling type
mismatches if when linking an internal foo to an external foo.

llvm-svn: 52134

llvm-svn: 52133