Implement most of the missing methods to make SuccIterator random access.
operator[] is still missing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93363 91177308-0d34-0410-b5e6-96231b3b80d8
that I want to completely eliminate. Add fixme's so I remember this
in the future, and add the missing helper that they should be upgraded
to use instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93300 91177308-0d34-0410-b5e6-96231b3b80d8
instead of returning it in an std::string. Based on this change:
1. Change TargetLoweringObjectFileCOFF::getCOFFSection to take a StringRef
2. Change a bunch of targets to call makeNameProper with a smallstring,
making several of them *much* more efficient.
3. Rewrite Mangler::makeNameProper to not build names and then prepend
prefixes, not use temporary std::strings, and to avoid other crimes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93298 91177308-0d34-0410-b5e6-96231b3b80d8
non-templated IRBuilderBase class. Move that large CreateGlobalString
out of line, eliminating the need to #include GlobalVariable.h in IRBuilder.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92227 91177308-0d34-0410-b5e6-96231b3b80d8
mainly used in debugging and/or assert situations. It should make the compiler
and the static analyzer stop nagging us about them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92181 91177308-0d34-0410-b5e6-96231b3b80d8
simply passes output to errs(). If -debug-buffer-size=N is set N > 0,
dbgs() buffers its output until program termination and dumps the last N
characters sent to it. This is handy when debugging very large inputs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92002 91177308-0d34-0410-b5e6-96231b3b80d8
and outputs it when explicitly flushed. The intent is to use it in
situations such as debug output logging where a signal handler can take
care of flushing the buffer at program termination.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92001 91177308-0d34-0410-b5e6-96231b3b80d8
it changes raw_fd_ostream::preferred_buffer_size to return zero on
a scary stat failure instead of setting the stream to an error state.
This method really should not mutate the stream.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91740 91177308-0d34-0410-b5e6-96231b3b80d8
isPodLike type trait. This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91421 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90132 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90131 91177308-0d34-0410-b5e6-96231b3b80d8
as the isSigned bool to CreateIntCast by having this resolve to a call
to a private method, rather than by using a gcc attribute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89067 91177308-0d34-0410-b5e6-96231b3b80d8
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*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88913 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86636 91177308-0d34-0410-b5e6-96231b3b80d8
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
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85893 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85742 91177308-0d34-0410-b5e6-96231b3b80d8
GlobalOpt already deletes trivially dead functions/globals,
so GlobalDCE only adds values for cycles of dead things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85731 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85729 91177308-0d34-0410-b5e6-96231b3b80d8
stuff) to programmatically control the current debug flavor. While
I'm at it, doxygenate Debug.h and clean it up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85395 91177308-0d34-0410-b5e6-96231b3b80d8
Remove LowerAllocations pass.
Update some more passes to treate free calls just like they were treating FreeInst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85176 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84987 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84890 91177308-0d34-0410-b5e6-96231b3b80d8
s/validName/isValidName/g
s/with an Instruction/to an Instruction/g
s/RegisterMDKind/registerMDKind/g
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84689 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84522 91177308-0d34-0410-b5e6-96231b3b80d8
