pounding on Loop::contains (which is O(n) in the size of the loop), use a
sorted vector, which is O(log(N)) for each query. This speeds up Duraid's
horrible testcase from ~72s to ~31s in a debug build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29645 91177308-0d34-0410-b5e6-96231b3b80d8
blocks that target loop blocks.
Before, the code was run once per loop, and depended on the number of
predecessors each block in the loop had. Unfortunately, scanning preds can
be really slow when huge numbers of phis exist or when phis with huge numbers
of inputs exist.
Now, the code is run once per function and scans successors instead of preds,
which is far faster. In addition, the new code is simpler and is goto free,
woo.
This change speeds up a nasty testcase Duraid provided me from taking hours to
taking ~72s with a debug build. The functionality this implements is already
tested in the testsuite as Transforms/CodeExtractor/2004-03-13-LoopExtractorCrash.ll.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29644 91177308-0d34-0410-b5e6-96231b3b80d8
in the start of an array and a count of operands where applicable. In many
cases, the number of operands is known, so this static array can be allocated
on the stack, avoiding the heap. In many other cases, a SmallVector can be
used, which has the same benefit in the common cases.
I updated a lot of code calling getNode that takes a vector, but ran out of
time. The rest of the code should be updated, and these methods should be
removed.
We should also do the same thing to eliminate the methods that take a
vector of MVT::ValueTypes.
It would be extra nice to convert the dagiselemitter to avoid creating vectors
for operands when calling getTargetNode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29566 91177308-0d34-0410-b5e6-96231b3b80d8
method that took std::vector<SDOperand> to take a pointer to a first operand
and #operands.
This speeds up isel on kc++ by about 3%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29561 91177308-0d34-0410-b5e6-96231b3b80d8
selection is done. That's rather expensive especially in situations where it
isn't really needed.
Move back to a searching the predecessors, but make use of topological order
to trim the search space.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29559 91177308-0d34-0410-b5e6-96231b3b80d8
to build a loadable module is now correctly defined and documented so this
workaround isn't needed any longer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29553 91177308-0d34-0410-b5e6-96231b3b80d8
SlowOperatingInfo, Statistics). Besides providing an example of how to
use these facilities, it also serves to debug problems with runtime linking
when dlopening a loadable module. These three support facilities exercise
different combinations of Text/Weak Weak/Text and Text/Text linking
between the executable and the module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29552 91177308-0d34-0410-b5e6-96231b3b80d8
1. Change the usage of LOADABLE_MODULE so that it implies all the things
necessary to make a loadable module. This reduces the user's burdern to
get a loadable module correctly built.
2. Document the usage of LOADABLE_MODULE in the MakefileGuide
3. Adjust the makefile for lib/Transforms/Hello to use the new specification
for building loadable modules
4. Adjust the sample project to not attempt to build a shared library for
its little library. This was just wasteful and not instructive at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29551 91177308-0d34-0410-b5e6-96231b3b80d8
eliminates a bunch of std::map's in the SelectionDAG, replacing them with a
home-grown hashtable.
This is still a work in progress: not all the maps have been moved over and the
hashtable never resizes. That said, this still speeds up llc 20% on kimwitu++
with -fast -regalloc=local using a release build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29550 91177308-0d34-0410-b5e6-96231b3b80d8
the removal of directories. Using std::remove is indiscriminate and can
lead to the removal of things like /dev/null if run as root. The
Path::eraseFromDisk method ensures that we only ever remove regular files
or directories, but never character or block special nodes. This should
clear up the problem with usage like: llvm-as -o /dev/null which is used
in the llvm-test makefiles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29540 91177308-0d34-0410-b5e6-96231b3b80d8
Update ltld.[ch] to version 1.5.22.
Correct the notes about updating these tools (autoconf/README.TXT)
Add configure options for getting the correct option for including a whole
archive when linking.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29529 91177308-0d34-0410-b5e6-96231b3b80d8
1. Update an obsolete comment.
2. Make the sorting by base an explicit (though still N^2) step, so
that the code is more clear on what it is doing.
3. Partition uses so that uses inside the loop are handled before uses
outside the loop.
Note that none of these changes currently changes the code inserted by LSR,
but they are a stepping stone to getting there.
This code is the result of some crazy pair programming with Nate. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29493 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like libstdc++ implementation does not scale very well. Switch back
to using directly managed arrays.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29469 91177308-0d34-0410-b5e6-96231b3b80d8
down approach, inspired by discussions with Tanya.
This approach is significantly faster, because it does not need dominator
frontiers and it does not insert extraneous unused PHI nodes. For example, on
252.eon, in a release-asserts build, this speeds up LCSSA (which is the slowest
pass in gccas) from 9.14s to 0.74s on my G5. This code is also slightly smaller
and significantly simpler than the old code.
Amusingly, in a normal Release build (which includes the
"assert(L->isLCSSAForm());" assertion), asserting that the result of LCSSA
is in LCSSA form is actually slower than the LCSSA transformation pass
itself on 252.eon. I will see if Loop::isLCSSAForm can be sped up next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29463 91177308-0d34-0410-b5e6-96231b3b80d8
move the constant pool to .text
correctly print loads of labels
mark R0, R1, R2 and R3 as caller save
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29451 91177308-0d34-0410-b5e6-96231b3b80d8
2. Added argument to instruction scheduler creators so the creators can do
special things.
3. Repaired target hazard code.
4. Misc.
More to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29450 91177308-0d34-0410-b5e6-96231b3b80d8
The CFE refers to all single-register constraints (like "A") by their 16-bit
name, even though the 8 or 32-bit version of the register may be needed.
The X86 backend should realize what is going on and redecode the name back
to its proper form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29420 91177308-0d34-0410-b5e6-96231b3b80d8
fold them. This correctly truncates constants that are too large for the
destination slot and makes the code easier to understand. This fixes PR853
and Regression/CodeGen/X86/2006-07-28-AsmPrint-Long-As-Pointer.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29408 91177308-0d34-0410-b5e6-96231b3b80d8
instead of throwing an exception. This reduces the amount of code that is
exposed to exceptions (e.g. FileUtilities), though it is clearly only one step
along the way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@29395 91177308-0d34-0410-b5e6-96231b3b80d8
