modify the type and location debug information for these variables to match the
programmer's expectations.

llvm-svn: 80625

SCEVUnknowns, as the non-SCEVUnknown cases in the getSCEVAtScope code
can also end up repeatedly climing through the same expression trees,
which can be unusably slow when the trees are very tall.

Also, add a quick check for SCEV pointer equality to the main
SCEV comparison routine, as the full comparison code can be expensive
in the case of large expression trees.

These fix compile-time problems in some pathlogical cases.

llvm-svn: 80623

llvm-svn: 80621

llvm-svn: 80620

llvm-svn: 80618

llvm-svn: 80615

 - Down to 7 failures on 403.gcc.

llvm-svn: 80605

Stop printing old asm printing code inline with -experimental-asm-printer (this allows diffing and assembling the .s)

llvm-svn: 80604

llvm-svn: 80603

llvm-svn: 80602

llvm-svn: 80601

llvm-svn: 80595

handling on x86-32 linux.

llvm-svn: 80592

This fixes leaks from LLVMContext in multithreaded apps.
Since constants are only deleted if they have no uses, it is safe to not delete
a Module on shutdown, as many single-threaded tools do.
Multithreaded apps should however delete the Module before destroying the
Context to ensure that there are no leaks (assuming they use a different context
for each thread).

llvm-svn: 80590

llvm-svn: 80589

llvm-svn: 80584

llvm-svn: 80578

llvm-svn: 80577

Also, use MCInst::print instead of custom code in MCAsmPrinter.

llvm-svn: 80575

llvm-svn: 80573

llvm-svn: 80572

llvm-svn: 80570

llvm-mc: Switch MCExpr construction to using static member functions, and taking the MCContext (which now owns all MCExprs).

llvm-svn: 80569

llvm-svn: 80567

stem from the fact that we have two types of passes that need to update it:

1. callgraphscc and module passes that are explicitly aware of it
2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes
   by the CGSCC Passmgr.

In the case of #1, we can reasonably expect the passes to update the call
graph just like any analysis.  However, functionpasses are not and generally
should not be CG aware.  This has caused us no end of problems, so this takes
a new approach.  Logically, the CGSCC Pass manager can rescan every function 
after it runs a function pass over it to see if the functionpass made any 
updates to the IR that affect the callgraph.  This allows it to catch new calls
introduced by the functionpass.

In practice, doing this would be slow.  This implementation keeps track of
whether or not the current scc is dirtied by a function pass, and, if so, 
delays updating the callgraph until it is actually needed again.  This was
we avoid extraneous rescans, but we still have good invariants when the
callgraph is needed.

Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode
to use a CallBackVH for the callsite entry of the CallGraphNode.  This way
we can immediately remove entries from the callgraph when a FunctionPass is
active instead of having dangling pointers.  The current pass tries to tolerate
these dangling pointers, but it is just an evil hack.

This is related to PR3601/4835/4029.  This also reverts r80541, a hack working
around the sad lack of invariants.

llvm-svn: 80566

from runOnFunction

llvm-svn: 80562

llvm-svn: 80542

in the callgraph, see the big comment at the top of the testcase.

llvm-svn: 80541

llvm-svn: 80540

llvm-svn: 80539

instcombine is changing stuff.

llvm-svn: 80538

changes: SimplifyDemandedBits can't use the builder yet because it
has the wrong insertion point.  This fixes a crash building
MultiSource/Benchmarks/PAQ8p

llvm-svn: 80537

instead of CallGraphNode*'s.  This also papers over a callgraph
problem where a pass (in this case, MemCpyOpt) introduces a new
function into the module (llvm.memset.i64) but doesn't add it to
the call graph (nor should it, since it is a function pass).

While it might be a good idea for MemCpyOpt to not synthesize 
functions in a runOnFunction(), there is no need for FunctionAttrs
to be boneheaded, so fix it there.  This fixes an assertion building
176.gcc.

llvm-svn: 80535

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

llvm-svn: 80532

Shared landing pads run into trouble with SJLJ, as the dispatch table is
mapped to call sites, and merging the pads will throw that off. There needs
to be a one-to-one mapping of landing pad exception table entries to invoke
call points.

Detecting the shared pad during lowering of SJLJ info insn't sufficient, as
the dispatch function may still need separate destinations to properly
handle phi-nodes.

llvm-svn: 80530

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

llvm-svn: 80515

is itself a bitcast.  Since we have gep(bitcast(bitcast(y))) in this
case, just wait for the two bitcasts to get zapped.  This prevents
instcombine from confusing some aliasing stuff, and allows it to
directly eliminate the load in the testcase.

llvm-svn: 80508