the iterator hints we have to speed up overlaps(). This speeds linscan up
by about .2s (out of 8.7) on 175.vpr for PPC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17935 91177308-0d34-0410-b5e6-96231b3b80d8
* Eliminate the releaseMemory method, this is not an analysis
* Change the fixed, active, and inactive lists of intervals to maintain an
iterator for the current position in the interval. This allows us to do
constant time increments of the iterator instead of having to do a binary
search to find our liverange in our liveinterval all of the time, which
substantially speeds up cases where LiveIntervals have many LiveRanges
- which is very common for physical registers. On targets with many
physregs, this can make a noticable difference.
With a release build of LLC for PPC, this halves the time in
processInactiveIntervals and processActiveIntervals, from 1.5s to .75s.
This also lays the ground for more to come.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17933 91177308-0d34-0410-b5e6-96231b3b80d8
* ensure trailing spaces are eliminated so they don't factor into the
length of a member's name.
* make sure all the bytes of a name are written even if the name ends in
multiple null characters (bug in OSX ar)
* make sure we provide the full member name when searching for symbols so
the module name is not accidentally duplicated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17918 91177308-0d34-0410-b5e6-96231b3b80d8
*do* include the length of the long file in the length of the member and
they are *not* null terminated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17909 91177308-0d34-0410-b5e6-96231b3b80d8
by splicing function bodies from the src module to the destination module.
This speeds up linking quite a bit, e.g. gccld time on 176.gcc from 26s -> 20s
when forming the .rbc file, with a profile build. One of the really strange
but cool effects of this patch is that it speeds up the optimizers as well,
from 12s -> 10.7s, presumably because of better locality???
In any case, this is just a first step. We can trivially get rid of the
LocalMap now and do other simplifications.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17893 91177308-0d34-0410-b5e6-96231b3b80d8
* Make the numVbrBytes function more efficient and better documented \
* Fix a bug in name truncation \
* Add comments before functions \
* Get rid of functions that are now inlined into the header \
* Do not have Archive doing symbol table printing \
* Put assert comments into the assert so they print out \
* Make sure foreign symbol tables are written
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17884 91177308-0d34-0410-b5e6-96231b3b80d8
* Make sure we write out the foreign symbol table if we read one \
* Make the padding calculation more efficiently and avoid Solaris warnings
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17883 91177308-0d34-0410-b5e6-96231b3b80d8
* get rid of (void) construct in function declarations
* make toString a const member
* add a default implementation of toString for Win32
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17873 91177308-0d34-0410-b5e6-96231b3b80d8
* Clean up the StatusInfo constructor to construct all members and give
them reasonable values.
* Get rid of the Vector typedef and make the interface to
getDirectoryContent use a std::set instead of a std::vector so the dir
content is sorted.
* Make the getStatusInfo method const and not return a useless boolean.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17872 91177308-0d34-0410-b5e6-96231b3b80d8
* Get rid of "emitMaybePCRelativeValue", either we want to emit a PC relative
value or not: drop the maybe BS. As it turns out, the only places where
the bool was a variable coming in, the bool was a dynamic constant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17867 91177308-0d34-0410-b5e6-96231b3b80d8
