Use CallbackVH, instead of WeakVH, to hold MDNode elements.
Use FoldingSetNode to unique MDNodes in a context.
Use CallbackVH hooks to update context's MDNodeSet appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80868 91177308-0d34-0410-b5e6-96231b3b80d8
instruction tables to support segmented addressing (and other objects
of obscure type).
Modified the X86 assembly printers to handle these new operand types.
Added JMP and CALL instructions that use segmented addresses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80857 91177308-0d34-0410-b5e6-96231b3b80d8
Use FoldingSetNode to unique MDNodes in a context.
Use CallbackVH hooks to update context's MDNodeSet appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80839 91177308-0d34-0410-b5e6-96231b3b80d8
AlwaysOpaqueTy is always NULL at this point, and it causes an assertion failure.
Fix it by using the just constructed tmp instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80780 91177308-0d34-0410-b5e6-96231b3b80d8
and we get the original pointer type. This doesn't mean that we're
at the first pointer being indexed. Correct the predicate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80762 91177308-0d34-0410-b5e6-96231b3b80d8
desired triplet is a sub-target, e.g. thumbv7 vs. arm host). Reverting the
patch isn't quite right either since the previous behavior does not allow the
triplet to be overridden with -march.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80742 91177308-0d34-0410-b5e6-96231b3b80d8
CGSCC passes make change to ensure they are updating the callgraph correctly
(when assertions are enabled).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80698 91177308-0d34-0410-b5e6-96231b3b80d8
don't alias. Remove an old and poorly reduced testcase that fails
with this transform for reasons unrelated to the original test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80693 91177308-0d34-0410-b5e6-96231b3b80d8
Add MO flags to simplify the printing of relocations.
Remove the support for printing large code model relocs (which
aren't supported anyway).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80691 91177308-0d34-0410-b5e6-96231b3b80d8
Add statistics for regular edge profiling, this enables the comparation of the
number of edges inserted by regular and optimal edge profiling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80668 91177308-0d34-0410-b5e6-96231b3b80d8
Optimal edge profiling is only possible when blocks with no predecessors get an
virtual edge (BB,0) that counts the execution frequencies of this
function-exiting blocks.
This patch makes the necessary changes before actually enabling optimal edge profiling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80667 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a pass to verify the current profile against the flow conditions.
This is very helpful when later on trying to perserve the profiling information
during all passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80666 91177308-0d34-0410-b5e6-96231b3b80d8
for sanity. This didn't turn up any bugs.
Change CallGraphNode to maintain its "callsite" information in the
call edges list as a WeakVH instead of as an instruction*. This fixes
a broad class of dangling pointer bugs, and makes CallGraph have a number
of useful invariants again. This fixes the class of problem indicated
by PR4029 and PR3601.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80663 91177308-0d34-0410-b5e6-96231b3b80d8
tied to different source registers, the TwoAddressInstructionPass needs to
be smarter. Change it to check before replacing a source register whether
that source register is tied to a different destination register, and if so,
defer handling it until a subsequent iteration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80654 91177308-0d34-0410-b5e6-96231b3b80d8
makes an eggregious hack somewhat more palatable. Bringing the LSDA forward
and making it a GV available for reference would be even better, but is
beyond the scope of what I'm looking to solve at this point.
Objective C++ code could generate function names that broke the previous
scheme. This fixes that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80649 91177308-0d34-0410-b5e6-96231b3b80d8
modify the type and location debug information for these variables to match the
programmer's expectations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80625 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80623 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80590 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
changes: SimplifyDemandedBits can't use the builder yet because it
has the wrong insertion point. This fixes a crash building
MultiSource/Benchmarks/PAQ8p
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80537 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80535 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80533 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80530 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80527 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80508 91177308-0d34-0410-b5e6-96231b3b80d8
workslist and is set to insert new instructions before the current one.
Convert a bunch of stuff that used to call InsertNewInstBefore over to
use it, greatly simplifying code and making it more natural.
There is still a lot more to go, but this is a good start.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80492 91177308-0d34-0410-b5e6-96231b3b80d8
if the operand is not an instruction.
Simplify most uses of AddOperandsToWorkList to use AddValue and
inline it into the one remaining callsite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80488 91177308-0d34-0410-b5e6-96231b3b80d8
former looks too much like AddUsersToWorkList and keeps
confusing me.
Remove AddSoonDeadInstToWorklist and change its two callers
to do the same thing in a simpler way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80486 91177308-0d34-0410-b5e6-96231b3b80d8
into their callers. simplify ReplaceInstUsesWith. Make
EraseInstFromFunction only add operands to the worklist if
there aren't too many of them (this was a scalability win
for crazy programs that was only infrequently enforced).
Switch more code to using EraseInstFromFunction instead of
duplicating it inline. Change some fcmp/icmp optimizations
to modify fcmp/icmp in place instead of creating a new one
and deleting the old one just to change the predicate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80483 91177308-0d34-0410-b5e6-96231b3b80d8
does constant folding of gep's: this is already handled in
a more general way.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80475 91177308-0d34-0410-b5e6-96231b3b80d8
