llvm-svn: 52309

llvm-svn: 52308

llvm-svn: 52306

llvm-svn: 52305

wants a 'nocapture' predicate.

llvm-svn: 52304

in this file, no other changes.

llvm-svn: 52303

the purposes of escape analysis.

llvm-svn: 52302

pointer derived from a local allocation, if the local allocation
never escapes, the pointers can't alias.  This implements PR2436

llvm-svn: 52301

Assign indices to empty basic blocks.  This will be necessary for StrongPHIElimination in the near future.

llvm-svn: 52300

This fixes several minor bugs (such as returning noalias
for comparisons between external weak functions an null) but
is mostly a cleanup.

llvm-svn: 52299

llvm-svn: 52298

them based on the end-compiler's capabilities.  This fixes PR2453

llvm-svn: 52297

llvm-svn: 52296

llvm-svn: 52295

llvm-svn: 52294

not valid if the load is volatile.  Hopefully
all wrong DAG combiner transforms of volatile
loads and stores have now been caught.

llvm-svn: 52293

a non-constant index.

llvm-svn: 52292

take into account the instrucion pointed by InsertPt. Thanks to it, 
returning the new value of InsertPt to the InsertBinop() caller can be 
avoided. The bug was, actually, in visitAddRecExpr() method which wasn't 
correctly handling changes of InsertPt. There shouldn't be any 
performance regression, as -gvn pass (run after -indvars) removes any 
redundant binops.

llvm-svn: 52291

llvm-svn: 52290

llvm-svn: 52289

llvm-svn: 52288

With this more general way, -native and -native-cbe options are handled too.

llvm-svn: 52287

llvm-svn: 52286

llvm-svn: 52285

This bug made llvm-ld unable to function with "-native" option, since the process that was used to call 'gcc' was crashing.

llvm-svn: 52284

on some code when !AfterLegalize - but since
this whole code section is turned off by an
"if (0)" it's not really turning anything on.

llvm-svn: 52276

Add a safety measure. It isn't safe to assume in ScalarEvolutionExpander that
all loops are in canonical form (but it should be safe for loops that have
AddRecs).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

llvm-svn: 52275

llvm-svn: 52270

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

llvm-svn: 52261

llvm-svn: 52260

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

llvm-svn: 52251

XFAIL some tests that became failing due to the extra error reporting recently. PR's are created for these.

llvm-svn: 52250

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

Make getTruncateOrZeroExtend a method on ScalarEvolution, and use it.

llvm-svn: 52248