any attempts by LLI to use varargs (possibly left over from the introduction
of IntrinsicLowering??)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11370 91177308-0d34-0410-b5e6-96231b3b80d8
Rename SetMachineOperandConst's formal parameters to match other methods here.
Mark some methods as being used only by the SPARC back-end.
Fix a missing-paren bug in OutputValue().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11363 91177308-0d34-0410-b5e6-96231b3b80d8
MachineBasicBlock. Also change opcode to a short and numImplicitRefs
to an unsigned char so that overall MachineInstr's size stays the
same.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11357 91177308-0d34-0410-b5e6-96231b3b80d8
ilist of MachineInstr objects. This allows constant time removal and
insertion of MachineInstr instances from anywhere in each
MachineBasicBlock. It also allows for constant time splicing of
MachineInstrs into or out of MachineBasicBlocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11340 91177308-0d34-0410-b5e6-96231b3b80d8
MO_VirtualRegister but if the register number is one of a physical
register is it considered as a physical register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11315 91177308-0d34-0410-b5e6-96231b3b80d8
more of a testcase for profiling information than anything that should reasonably
be used, but it's a starting point. When I have more time I will whip this into
better shape.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11311 91177308-0d34-0410-b5e6-96231b3b80d8
Having a proper 'select' instruction would allow the elimination of a lot
of the special case cruft in this patch, but we don't have one yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11307 91177308-0d34-0410-b5e6-96231b3b80d8
passed into main, make sure they use the return value of the init call
instead of the one passed in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11262 91177308-0d34-0410-b5e6-96231b3b80d8
I will observe that the concept of using WriteAsOperand is completely broken,
but then we all knew that, didn't we?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11255 91177308-0d34-0410-b5e6-96231b3b80d8
in this for programs with lots of types (like the testcase in PR224).
The problem was that the type ID that the outer vector was using was not
very dense (as many types are getting resolved), so the vector is large
and gets reallocated a lot.
Since there are a lot of values in the program (the .ll file is 10M),
each reallocation has to copy the subvectors, which is also quite slow
(this wouldn't be a problem if C++ supported move semantics, but it
doesn't, at least not yet :(
Changing the outer data structure to a map speeds a release build of
llvm-as up from 11.21s to 5.13s on the testcase in PR224.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11244 91177308-0d34-0410-b5e6-96231b3b80d8
this speeds up a release llvm-as from 21.95s to 11.21s, because before it
would do an expensive traversal of the type-graph of every type resolved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11242 91177308-0d34-0410-b5e6-96231b3b80d8
type at the same time, resolve the upreferences to each other before resolving
it to the outer type. This shaves off some time from the testcase in PR224, from
25.41s -> 21.72s.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11241 91177308-0d34-0410-b5e6-96231b3b80d8
instead of randomly groping about inside its outEdges array.
Make SchedGraph::addDummyEdges() use getNumOutEdges() instead of
outEdges.size().
Get rid of ifdefed-out code in SchedGraph::buildGraph().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11238 91177308-0d34-0410-b5e6-96231b3b80d8
consistent across the various type classes, we can factor out a LOT more
almost-identical code. Also, add a couple of temporary statistics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11232 91177308-0d34-0410-b5e6-96231b3b80d8
all of the ad-hoc storage of contained types. This allows getContainedType to
not be virtual, and allows us to entirely delete the TypeIterator class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11230 91177308-0d34-0410-b5e6-96231b3b80d8
contains the type we are looking for, just search the immediately used types.
We can only do this because we keep the "current" type in the nesting level
as we decrement upreferences.
This change speeds up the testcase in PR224 from 50.4s to 22.08s, not
too shabby.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11221 91177308-0d34-0410-b5e6-96231b3b80d8
the Virt2PhysRegMap std::map with an std::vector. This speeds up the
register allocator another (almost) 40%, from .72->.45s in a release build
of LLC on 253.perlbmk.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11219 91177308-0d34-0410-b5e6-96231b3b80d8
This speeds up live variables a lot, from .60/.39s -> .47/.26s in LLC, for
the first/second pass respectively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11216 91177308-0d34-0410-b5e6-96231b3b80d8
from physical registers, and they are always dense, it makes sense to not have
a ton of RBtree overhead. This change speeds up regalloclocal about ~30% on
253.perlbmk, from .35s -> .27s in the JIT (in LLC, it goes from .74 -> .55).
Now live variable analysis is the slowest codegen pass. Of course it doesn't
help that we have to run it twice, because regalloclocal doesn't update it,
but even if it did it would be the slowest pass (now it's just the 2x slowest
pass :(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11215 91177308-0d34-0410-b5e6-96231b3b80d8
1. The "work" was not in the assert, so it was punishing the optimized release
2. getNamedFunction is _very_ expensive in large programs. It is not designed
to be used like this, and was taking 7% of the execution time of the code
generator on perlbmk.
Since the assert "can never fail", I'm just killing it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11214 91177308-0d34-0410-b5e6-96231b3b80d8
This causes the JIT, or LLC'd program to print out a nice message, explaining
WHY the program aborted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11184 91177308-0d34-0410-b5e6-96231b3b80d8
removeDeadNodes is called, only call it at the end of the pass being run.
This saves 1.3 seconds running DSA on 177.mesa (5.3->4.0s), which is
pretty big. This is only possible because of the automatic garbage
collection done on forwarding nodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11178 91177308-0d34-0410-b5e6-96231b3b80d8
DSGraphs while they are forwarding. When the last reference to the forwarding
node is dropped, the forwarding node is autodeleted. This should simplify
removeTriviallyDead nodes, and is only (efficiently) possible because we are
using an ilist of dsnodes now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11175 91177308-0d34-0410-b5e6-96231b3b80d8
slots each. As a concequence they get numbered as 0, 2, 4 and so
on. The first slot is used for operand uses and the second for
defs. Here's an example:
0: A = ...
2: B = ...
4: C = A + B ;; last use of A
The live intervals should look like:
A = [1, 5)
B = [3, x)
C = [5, y)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11141 91177308-0d34-0410-b5e6-96231b3b80d8
The problem is that the dominator update code didn't "realize" that it's
possible for the newly inserted basic block to dominate anything. Because
it IS possible, stuff was getting updated wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11137 91177308-0d34-0410-b5e6-96231b3b80d8
complete rewrite of load-vn will make it a bit faster. This changes speeds up
the gcse pass (which uses load-vn) from 25.45s to 0.42s on the testcase in
PR209.
I've also verified that this gives the exact same results as the old one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11132 91177308-0d34-0410-b5e6-96231b3b80d8
1. Don't scan to the end of alloca instructions in the caller function to
insert inlined allocas, just insert at the top. This saves a lot of
time inlining into functions with a lot of allocas.
2. Use splice to move the alloca instructions over, instead of remove/insert.
This allows us to transfer a block at a time, and eliminates a bunch of
silly symbol table manipulations.
This speeds up the inliner on the testcase in PR209 from 1.73s -> 1.04s (67%)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11118 91177308-0d34-0410-b5e6-96231b3b80d8
and that basic block ends with a return instruction. In this case, we can just splice
the cloned "body" of the function directly into the source basic block, avoiding a lot
of rearrangement and splitBasicBlock's linear scan over the split block. This speeds up
the inliner on the testcase in PR209 from 2.3s to 1.7s, a 35% reduction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11116 91177308-0d34-0410-b5e6-96231b3b80d8
before we delete the original call site, allowing slight simplifications of
code, but nothing exciting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11109 91177308-0d34-0410-b5e6-96231b3b80d8
process. The only optimization we did so far is to avoid creating a
PHI node, then immediately destroying it in the common case where the
callee has one return statement. Instead, we just don't create the return
value. This has no noticable performance impact, but paves the way for
future improvements.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11108 91177308-0d34-0410-b5e6-96231b3b80d8
to add the cloned block to. This allows the block to be added to the function
immediately, and all of the instructions to be immediately added to the function
symbol table, which speeds up the inliner from 3.7 -> 3.38s on the PR209.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11107 91177308-0d34-0410-b5e6-96231b3b80d8
instead of a loop that is really inefficient with large basic blocks.
This speeds up the inliner pass on the testcase in PR209 from 13.8s to 2.24s
which still isn't exactly speedy, but is a lot better. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11105 91177308-0d34-0410-b5e6-96231b3b80d8
process them all as a group. This speeds up SRoA/mem2reg from 28.46s to
0.62s on the testcase from PR209.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11100 91177308-0d34-0410-b5e6-96231b3b80d8
Basically we store floating point values as their integral components, instead of relying
on the semantics of floating point < to differentiate between values. This is likely to
make the map search be faster anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11064 91177308-0d34-0410-b5e6-96231b3b80d8
registers (not as the max number of registers).
Change toSpill from a std::set into a std::vector<bool>.
Use the reverse iterator adapter to do a reverse scan of allocatable
registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11061 91177308-0d34-0410-b5e6-96231b3b80d8
Move Passes.h (which defines the interface to this file) to the top.
Move statistics to the top of the file.
Add a comment
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11034 91177308-0d34-0410-b5e6-96231b3b80d8
of a linear search to find the first range for comparisons. This cuts
down the linear scan register allocator running time by a factor of 3
in 254.perlbmk and by a factor of 2.2 in 176.gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11030 91177308-0d34-0410-b5e6-96231b3b80d8
Simplification of LiveIntervals::Interval::overlaps() and addition of
examples to overlaps() and liveAt() to make them clearer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11028 91177308-0d34-0410-b5e6-96231b3b80d8
FP_REG_KILL instructions at the end of blocks involved with critical edges.
Fix a bug where FP_REG_KILL instructions weren't inserted in fall through
unconditional branches. Perhaps this will fix some linscan problems?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11019 91177308-0d34-0410-b5e6-96231b3b80d8
the globals directly. This doesn't save any substantial time, however, because the
globals graph only contains globals!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10997 91177308-0d34-0410-b5e6-96231b3b80d8
function to find the globals, iterate over all of the globals directly. This
speeds the function up from 14s to 6.3s on perlbmk, reducing DSA time from
53->46s.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10996 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces the number of nodes allocated, then immediately merged and DNE'd
from 2193852 to 1298049. unfortunately this only speeds DSA up by ~1.5s (of
53s), because it's spending most of its time waddling through the scalar map :(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10992 91177308-0d34-0410-b5e6-96231b3b80d8
Also, use RC::merge when possible, reducing the number of nodes allocated, then immediately merged away from 2985444 to 2193852 on perlbmk.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10991 91177308-0d34-0410-b5e6-96231b3b80d8
it to be off. If it looks like it's completely unnecessary after testing, I
will remove it completely (which is the hope).
* Callers of the DSNode "copy ctor" can not choose to not copy links.
* Make node collapsing not create a garbage node in some cases, avoiding a
memory allocation, and a subsequent DNE.
* When merging types, allow two functions of different types to be merged
without collapsing.
* Use DSNodeHandle::isNull more often instead of DSNodeHandle::getNode() == 0,
as it is much more efficient.
*** Implement the new, more efficient reachability cloner class
In addition to only cloning nodes that are reachable from interesting
roots, this also fixes the huge inefficiency we had where we cloned lots
of nodes, only to merge them away immediately after they were cloned.
Now we only actually allocate a node if there isn't one to merge it into.
* Eliminate the now-obsolete cloneReachable* and clonePartiallyInto methods
* Rewrite updateFromGlobalsGraph to use the reachability cloner
* Rewrite mergeInGraph to use the reachability cloner
* Disable the scalar map scanning code in removeTriviallyDeadNodes. In large
SCC's, this is extremely expensive. We need a better data structure for the
scalar map, because we really want to scan the unique node handles, not ALL
of the scalars.
* Remove the incorrect SANER_CODE_FOR_CHECKING_IF_ALL_REFERRERS_ARE_FROM_SCALARMAP code.
* Move the code for eliminating integer nodes from the trivially dead
eliminator to the dead node eliminator.
* removeDeadNodes no longer uses removeTriviallyDeadNodes, as it contains a
superset of the node removal power.
* Only futz around with the globals graph in removeDeadNodes if it is modified
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10987 91177308-0d34-0410-b5e6-96231b3b80d8
efficient in the case where a function calls into the same graph multiple times
(ie, it either contains multiple calls to the same function, or multiple calls
to functions in the same SCC graph)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10986 91177308-0d34-0410-b5e6-96231b3b80d8
when joining we need to check if we overlap with the second interval
or any of its aliases.
Also make joining intervals the default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10973 91177308-0d34-0410-b5e6-96231b3b80d8
out that the problem was actually the writer writing out a 'null' value
because it didn't normalize it. This fixes:
test/Regression/Assembler/2004-01-22-FloatNormalization.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10967 91177308-0d34-0410-b5e6-96231b3b80d8
is a move between two registers, at least one of the registers is
virtual and the two live intervals do not overlap.
This results in about 40% reduction in intervals, 30% decrease in the
register allocators running time and a 20% increase in peephole
optimizations (mainly move eliminations).
The option can be enabled by passing -join-liveintervals where
appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10965 91177308-0d34-0410-b5e6-96231b3b80d8
virtReg lives on the stack. Now a virtual register has an entry in the
virtual->physical map or the virtual->stack slot map but never in
both.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10958 91177308-0d34-0410-b5e6-96231b3b80d8
map was only used to implement a marginal GlobalsGraph optimization, and it
actually slows the analysis down (due to the overhead of keeping it), so just
eliminate it entirely.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10955 91177308-0d34-0410-b5e6-96231b3b80d8
in terms of it.
Though clonePartiallyInto is not cloning partial graphs yet, this change
dramatically speeds up inlining of graphs with many scalars. For example,
this change speeds up the BU pass on 253.perlbmk from 69s to 36s, because
it avoids iteration over the scalar map, which can get pretty large.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10951 91177308-0d34-0410-b5e6-96231b3b80d8
fact "profitable" to do so. This makes compactification "free" for small
programs (ie, it is completely disabled) and even helps large programs by
not having to encode pointless compactification planes.
On 176.gcc, this saves 50K from the bytecode file, which is, alas only
a couple percent.
This concludes my head bashing against the bytecode format, at least for
now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10922 91177308-0d34-0410-b5e6-96231b3b80d8
This shrinks the bytecode file for 176.gcc by about 200K (10%), and 254.gap by
about 167K, a 25% reduction. There is still a lot of room for improvement in
the encoding of the compaction table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10915 91177308-0d34-0410-b5e6-96231b3b80d8
This shrinks the bytecode file for 176.gcc by about 200K (10%), and 254.gap by
about 167K, a 25% reduction. There is still a lot of room for improvement in
the encoding of the compaction table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10914 91177308-0d34-0410-b5e6-96231b3b80d8
the bytecode file for 176.gcc by about 200K (10%), and 254.gap by about 167K,
a 25% reduction. There is still a lot of room for improvement in the encoding
of the compaction table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10913 91177308-0d34-0410-b5e6-96231b3b80d8
Fix some problem cases where I was building the slot calculator in bytecode
writer mode instead of asmwriter mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10911 91177308-0d34-0410-b5e6-96231b3b80d8
type planes. This saves about 5k on 176.gcc, and is needed for a subsequent
patch of mine I'm working on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10908 91177308-0d34-0410-b5e6-96231b3b80d8
