llvm-svn: 83274

llvm-svn: 80540

indirect function pointer, inline it, then go to delete the body.
The problem is that the callgraph had other references to the function,
though the inliner had no way to know it, so we got a dangling pointer
and an invalid iterator out of the deal.

The fix to this is pretty simple: stop the inliner from deleting the
function by knowing that there are references to it.  Do this by making
CallGraphNodes contain a refcount.  This requires moving deletion of 
available_externally functions to the module-level cleanup sweep where
it belongs.

llvm-svn: 80533

argpromotion and structretpromote.  Basically, when replacing
a function, they used the 'changeFunction' api which changes
the entry in the function map (and steals/reuses the callgraph
node).

This has some interesting effects: first, the problem is that it doesn't
update the "callee" edges in any callees of the function in the call graph.
Second, this covers for a major problem in all the CGSCC pass stuff, which 
is that it is completely broken when functions are deleted if they *don't*
reuse a CGN.  (there is a cute little fixme about this though :).

This patch changes the protocol that CGSCC passes must obey: now the CGSCC 
pass manager copies the SCC and preincrements its iterator to avoid passes
invalidating it.  This allows CGSCC passes to mutate the current SCC.  However
multiple passes may be run on that SCC, so if passes do this, they are now
required to *update* the SCC to be current when they return.

Other less interesting parts of this patch are that it makes passes update
the CG more directly, eliminates changeFunction, and requires clients of
replaceCallSite to specify the new callee CGN if they are changing it.

llvm-svn: 80527

llvm-svn: 80334

calls into a function and if the calls bring in arrays, try to merge
them together to reduce stack size.  For example, in the testcase
we'd previously end up with 4 allocas, now we end up with 2 allocas.

As described in the comments, this is not really the ideal solution
to this problem, but it is surprisingly effective.  For example, on
176.gcc, we end up eliminating 67 arrays at "gccas" time and another
24 at "llvm-ld" time.

One piece of concern that I didn't look into: at -O0 -g with
forced inlining this will almost certainly result in worse debug
info.  I think this is acceptable though given that this is a case
of "debugging optimized code", and we don't want debug info to
prevent the optimizer from doing things anyway.

llvm-svn: 80215

llvm-svn: 80204

and other code cleanups.  No functionality change.

llvm-svn: 80199

the command line.  This gives llvm-gcc developers
a way to control inlining (documented as "not intended
for end users").

llvm-svn: 79966

- One formatting change.

No intended functionality change.

llvm-svn: 77717

 - Some clients which used DOUT have moved to DEBUG. We are deprecating the
   "magic" DOUT behavior which avoided calling printing functions when the
   statement was disabled. In addition to being unnecessary magic, it had the
   downside of leaving code in -Asserts builds, and of hiding potentially
   unnecessary computations.

llvm-svn: 77019

instead of getAnalysis<TargetData>().

llvm-svn: 76982

llvm-svn: 76284

and it wasn't generating calls through @PLT for these functions.
hasLocalLinkage() is now false for available_externally,
I attempted to fix the inliner and dce to handle available_externally properly.
It passed make check.

llvm-svn: 72328

llvm-svn: 67578

the inliner; prevents nondeterministic behavior
when the same address is reallocated.
Don't build call graph nodes for debug intrinsic calls;
they're useless, and there were typically a lot of them.

llvm-svn: 67311

llvm-svn: 62279

back to 200; 400 seems to be too high, loses more than
it gains.

llvm-svn: 62107

compensation for turning off gcc's inliner.  This gets
us closer to the amount of inlining we were getting before.
It is not a win on everything, of course, but seems to
gain overall.

llvm-svn: 62058

llvm-svn: 61969

llvm-svn: 59758

inlining function, then increase the stack protection level on the inlining
function.

llvm-svn: 59757

llvm-svn: 58744

function.
 - This explicitly models the costs for functions which should
   "always" or "never" be inlined. This fixes bugs where such costs
   were not previously respected.

llvm-svn: 58450

 - No functionality change.

llvm-svn: 58355

llvm-svn: 56716

s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g

This sets the stage 
- to implement function notes as function attributes and 
- to distinguish between function attributes and return value attributes.

This requires corresponding changes in llvm-gcc and clang.

llvm-svn: 56622

llvm-svn: 56527

Do not check isDeclaration() in hasNote(). It is clients' responsibility.

llvm-svn: 56524

Function Notes also. Function notes are stored at index ~0.

llvm-svn: 56511

llvm-svn: 56477

edges one by one by hand.

llvm-svn: 55836

llvm-svn: 55779

llvm-svn: 55745

llvm-svn: 55712

llvm-svn: 55708

llvm-svn: 55676

llvm-svn: 55673

several things that were neither in an anonymous namespace nor static
but not intended to be global.

llvm-svn: 51017

llvm-svn: 50696