llvm-svn: 80637

llvm-svn: 80633

llvm-svn: 80632

llvm-svn: 80631

them.  Move the code to make that change inside the conditional.

llvm-svn: 80630

llvm-svn: 80629

llvm-svn: 80627

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

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

although I don't think anyone cares about this
feature except Darwin.  PR 4825.

llvm-svn: 80596

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

llvm-svn: 80576

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

llvm-svn: 80575

llvm-svn: 80574

llvm-svn: 80573

llvm-svn: 80572

llvm-svn: 80571

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

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