If no destination label is available, just point to the node itself
instead of pointing to some source label. Source and destination labels are
not related in any way.
llvm-svn: 90132
Graphviz can layout the graphs better if a node does not contain source
ports. Therefore only print the ports if the source ports are useful,
that means are not labeled with the empty string "".
This patch also simplifies graphs without any edgeSourceLabels e.g. the
dominance trees.
llvm-svn: 90131
parameter of CreateIntCast then they get an error from the compiler
(or from the linker with a non-gcc compiler). Another possibility
is to flip the order of the DestTy and isSigned parameters, since you
should then get a compiler warning if you try to use a char* for a
Type*.
llvm-svn: 88913
This patch forbids implicit conversion of DenseMap::const_iterator to
DenseMap::iterator which was possible because DenseMapIterator inherited
(publicly) from DenseMapConstIterator. Conversion the other way around is now
allowed as one may expect.
The template DenseMapConstIterator is removed and the template parameter
IsConst which specifies whether the iterator is constant is added to
DenseMapIterator.
Actually IsConst parameter is not necessary since the constness can be
determined from KeyT but this is not relevant to the fix and can be addressed
later.
Patch by Victor Zverovich!
llvm-svn: 86636
This makes both logical sense (see below) and increases the
number of functions marked readnone/readonly by about 1-2%
in practice. The number of functions marked nocapture goes
up by about 5-10%. The reason it makes sense is shown by
the following example: if you run -functionattrs -inline on
it, then no attributes are assigned. But if you instead run
-inline -functionattrs then @f is marked readnone because the
simplifications produced by the inliner eliminate the store.
@x = external global i32
define void @w(i1 %b) {
br i1 %b, label %write, label %return
write:
store i32 1, i32 *@x
br label %return
return:
ret void
}
define void @f() {
call void @w(i1 0)
ret void
}
llvm-svn: 85893
1. we'd run simplifycfg at the very start, even though
the per function passes have already cleaned this up.
2. In the main per-function pipeline that is interlaced with inlining
etc, we would do instcombine, jump threading, simplifycfg *before*
doing SROA. SROA is much more likely to expose opportunities for
these passes than they are for SROA, so move SRoA up earlier.
also add some comments.
llvm-svn: 85742
ipconstprop and doesn't take much time. Just run it in its place.
This adds a testcase for it, which I plan to expand to cover other
"integration" cases, where we expect the optimizer to be able to
eliminate various things. Due to phase order issues we've regressed
in a number of areas and integration tests are the only way I see to
prevent this.
llvm-svn: 85729
Update all analysis passes and transforms to treat free calls just like FreeInst.
Remove RaiseAllocations and all its tests since FreeInst no longer needs to be raised.
llvm-svn: 84987
even when keys get RAUWed and deleted during its lifetime. By default the keys
act like WeakVHs, but users can pass a third template parameter to configure
how updates work and whether to do anything beyond updating the map on each
action.
It's also possible to automatically acquire a lock around ValueMap updates
triggered by RAUWs and deletes, to support the ExecutionEngine.
llvm-svn: 84890
The JITResolver maps Functions to their canonical stubs and all callsites for
lazily-compiled functions to their target Functions. To make Function
destruction work, I'm going to need to remove all callsites on destruction, so
this patch also adds the reverse mapping for that.
There was an incorrect assumption in here that the only stub for a function
would be the one caused by needing to lazily compile it, while x86-64 far calls
and dlsym-stubs could also cause such stubs, but I didn't look for a test case
that the assumption broke.
This also adds DenseMapInfo<AssertingVH> so I can use DenseMaps instead of
std::maps.
llvm-svn: 84522
buffer", while we work out a solution.
Dan convinced me that making debugging annoying for him is worse than 10x being
slower for me. :)
llvm-svn: 82553
This is designed for tracking a value even when it might move (like WeakVH), but it is an error to delete the referenced value (unlike WeakVH0. TrackingVH is templated like AssertingVH on the tracked Value subclass, it is an error to RAUW a tracked value to an incompatible type.
For implementation reasons the latter error is only diagnosed on accesses to a mis-RAUWed TrackingVH, because we don't want a virtual interface in a templated class.
The former error is also only diagnosed on access, so that clients are allowed to delete a tracked value, as long as they don't use it. This makes it easier for the client to reason about destruction.
llvm-svn: 82506
is.
- The problem is that formatted_ostream forces its underlying buffer to be
unbuffered, so if some client happens to wrap a formatted_ostream around
something, but still use the underlying stream, then we can end up writing on
a fully unbuffered output (which was never intended to be unbuffered).
- This makes clang (and presumably llvm-gcc) -emit-llvm -S a mere 10x faster.
llvm-svn: 82434
stringref because they may not be nul terminated. For options like -Lfoo
this now avoids a O(n) temporary std::strings where N is the length of
the string after -L.
llvm-svn: 82345
this is run after the 'standard function passes', SRoA was
recently run. This saves a domfrontier construction. Thanks
to Eli for noticing this.
llvm-svn: 82291
working. To support this, add an is_displayed() function to raw_ostream,
and generalize Process::StandardOutIsDisplayed and friends in order to
support it.
Also, call RemoveFileOnSignal before creating a file instead of after, so
that the file isn't left behind if the program is interrupted between when
the file is created and RemoveFileOnSignal is called.
While here, add a -S to llvm-extract and port it to IRReader so that it
supports assembly input.
llvm-svn: 81568
