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

Added test cases for presence and absence of __has_feature(objc_nonfragile_abi) with and without -fobjc-nonfragile-abi.

llvm-svn: 80593

handling on x86-32 linux.

llvm-svn: 80592

Added -fconstant-string-class= option.
Added __has_feature() test for non-fragile ABI.

llvm-svn: 80591

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

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

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

llvm-svn: 80534

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

llvm-svn: 80531

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

llvm-svn: 80529

llvm-svn: 80528