Do not rely on std::swap<Use>, provide a (faster) member function instead.
This change is primarily necessitated by MSVC++'s incompatibility with
declaring std::swap<Use> to be a friend of Use.
Also contains some minor tweaks to Use inline functions,
to undo pointless changes that sneaked in with the last merge.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51078 91177308-0d34-0410-b5e6-96231b3b80d8
This list does not provide the ability to go backwards in the list (its
more of an unordered collection, stored in the shape of a list).
This change means that use iterators are now only forward iterators, not
bidirectional.
This improves the memory usage of use lists from '5 + 4*#use' per value to
'1 + 4*#use'. While it would be better to reduce the multiplied factor,
I'm not smart enough to do so. This list also has slightly more efficient
operators for manipulating list nodes (a few less loads/stores), due to not
needing to be able to iterate backwards through the list.
This change reduces the memory footprint required to hold 176.gcc from
66.025M -> 57.687M, a 14% reduction. It also speeds up the compiler,
7.73% in the case of bytecode loading alone (release build loading 176.gcc).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@19956 91177308-0d34-0410-b5e6-96231b3b80d8
Based on the ilist changes avoid allocating an entire Use object for the
end of the Use chain. This saves 8 bytes of memory for each Value allocated
in the program. For 176.gcc, this reduces us from 69.5M -> 66.0M, a 5.3%
memory savings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@19925 91177308-0d34-0410-b5e6-96231b3b80d8
Move include/Config and include/Support into include/llvm/Config,
include/llvm/ADT and include/llvm/Support. From here on out, all LLVM
public header files must be under include/llvm/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16137 91177308-0d34-0410-b5e6-96231b3b80d8
this list (except use_size()) are constant time. Before the killUse method
(used whenever something stopped using a value) was linear time, and thus
very very slow for large programs.
This speeds GCCAS up _substantially_ on large programs: almost 2x for 176.gcc:
176.gcc: 77.07s -> 37.38s
177.mesa: 7.59s -> 5.57s
252.eon: 21.02s -> 19.52s (*)
253.perlbmk: 11.40s -> 13.05s
254.gap: 7.25s -> 7.42s
252.eon would speed up a whole lot more, but optimization time is being
dominated by the inlining pass, which needs to be fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9159 91177308-0d34-0410-b5e6-96231b3b80d8
