llvm-svn: 61745

llvm-svn: 61744

llvm-svn: 61743

In fact this also deletes those with linkonce linkage,
however this is currently dead because for the moment
aliases aren't allowed to have this linkage type.

llvm-svn: 61742

llvm-svn: 61715

Finalization occurs after all the FunctionPasses in the group have run, which
is clearly not what we want.

This also means that we have to make sure that we apply the right param 
attributes when creating a new function.

Also, add a missed optimization: strdup and strndup. NoCapture and 
NoAlias return!

llvm-svn: 61658

llvm-svn: 61632

llvm-svn: 61623

nocapture attributes to them.

llvm-svn: 61610

not have pointer type.  In particular, it may
be the condition argument for a select or a GEP
index.  While I was unable to construct a testcase
for which some bits of the original pointer are
captured due to one of these, it's very very close
to being possible - so play safe and exclude these
possibilities.

llvm-svn: 61580

the argument to be stored to an alloca by tracking uses
of the alloca.  This occurs 4 times (out of 7121, 0.05%)
in MultiSource/Applications, so may not be worth it.  On
the other hand, it is easy to do and fairly cheap.  The
functions it helps are: W_addcom and W_addlit in spiff;
process_args (argv) in d (make_dparser); ercPixConcealIMB
in JM/ldecod.

llvm-svn: 61570

change.

llvm-svn: 61569

functions that don't write can't leak a pointer except through 
the return value, so a void readonly function is implicitly nocapture.

Test these, and add a test that verifies that f1 calling f2 with an 
otherwise dead pointer gets both of them marked nocapture.

llvm-svn: 61552

leading comments.

llvm-svn: 61548

llvm-svn: 61538

 xor (or (icmp, icmp), true) -> and(icmp, icmp)

This is possible because of De Morgan's law.

llvm-svn: 61537

calculating nocapture attributes.

llvm-svn: 61535

llvm-svn: 61532

to work out (in a very simplistic way) which function
arguments (pointer arguments only) are only dereferenced
and so do not escape.  Mark such arguments 'nocapture'.

llvm-svn: 61525

and select instructions doesn't buy anything here
except extra complexity: the only difference in
the entire testsuite was that a readonly function
became readnone in MiBench/consumer-typeset.  Add
a comment about this.

llvm-svn: 61478

constants, since doing so is irrelevant for aliasing
purposes.  While this doesn't increase the total number
of functions marked readonly or readnone in MultiSource/
Applications (3089), it does result in 12 functions being
marked readnone rather than readonly.
Before:
  readnone: 820
  readonly: 2269
After:
  readnone: 832
  readonly: 2257

llvm-svn: 61469

llvm-svn: 61403

other SPEC breakage.  I'll be reverting all recent
changes shortly, this checking is mostly so this
change doesn't get lost.

llvm-svn: 61402

my last patch to this file.

The issue there was that all uses of an IV inside a loop
are actually references to Base[IV*2], and there was one
use outside that was the same but LSR didn't see the base
or the scaling because it didn't recurse into uses outside
the loop; thus, it used base+IV*scale mode inside the loop
instead of pulling base out of the loop.  This was extra bad
because register pressure later forced both base and IV into
memory.  Doing that recursion, at least enough
to figure out addressing modes, is a good idea in general;
the change in AddUsersIfInteresting does this.  However,
there were side effects....

It is also possible for recursing outside the loop to
introduce another IV where there was only 1 before (if
the refs inside are not scaled and the ref outside is).
I don't think this is a common case, but it's in the testsuite.
It is right to be very aggressive about getting rid of
such introduced IVs (CheckForIVReuse and the handling of
nonzero RewriteFactor in StrengthReduceStridedIVUsers).
In the testcase in question the new IV produced this way
has both a nonconstant stride and a nonzero base, neither
of which was handled before.  And when inserting 
new code that feeds into a PHI, it's right to put such 
code at the original location rather than in the PHI's 
immediate predecessor(s) when the original location is outside 
the loop (a case that couldn't happen before)
(RewriteInstructionToUseNewBase); better to avoid making
multiple copies of it in this case.

Also, the mechanism for keeping SCEV's corresponding to GEP's
no longer works, as the GEP might change after its SCEV
is remembered, invalidating the SCEV, and we might get a bad
SCEV value when looking up the GEP again for a later loop.  
This also couldn't happen before, as we weren't recursing
into GEP's outside the loop.

I owe some testcases for this, want to get it in for nightly runs.

llvm-svn: 61362

llvm-svn: 61358

llvm-svn: 61354

llvm-svn: 61353

llvm-svn: 61352

llvm-svn: 61350

llvm-svn: 61349

truely deleted. These will be expanded with further checks of all of the data
structures.

llvm-svn: 61347

llvm-svn: 61297

our optz'n will apply to it, then build the replacement vector only if needed.

llvm-svn: 61279

- CodeGenPrepare does not split loop back edges but it only knows about back edges of single block loops. It now does a DFS walk to find loop back edges.
- Use SplitBlockPredecessors to factor out common predecessors of the critical edge destination. This is disabled for now due to some regressions.

llvm-svn: 61248

llvm-svn: 61222

llvm-svn: 61219

Simplifying the sdiv might allow further simplifications for our users.

llvm-svn: 61196

llvm-svn: 61195

bit from the original function to the cloned one.

llvm-svn: 61194

llvm-svn: 61181