[llvm-commits] Speeding up instruction selection

[Roman Levenstein]

Hi Chris,

2008/3/7, Chris Lattner <clattner at apple.com>:
> On Mar 6, 2008, at 11:39 AM, Roman Levenstein wrote:
>
>
>  >>> One more observation:
>  >>> For big MBBs (like the one in big4,bc),
>  >>> llvm::SelectionDAG::ReplaceAllUsesOfValueWith can become a
>  >>> bottleneck
>  >>> if there are thousends of uses. SDNode.Uses is currently a
>  >>> small-vector, so that the deletion by means of removeUser is VERY,
>  >>> VERY slow.
>  >>
>  >>
>  >> If you are interested in this, it would be much better to use a
>  >> linked
>  >>  data structure like LLVM Value/Use does and MachineRegisterInfo/
>  >>  MachineOperand does.  This allows constant time for all def/use
>  >>  maintenance operations.
>  >
>  > OK. But how does it help with removal operations, which is done by
>  > removeUser() function called from ReplaceAllUsesOfValueWith ? In case
>  > of big MBBs, these lists would contain thousends of uses, The big4.bc
>  > contains for example 8000 elements in such a list. So, linear search
>  > would be a disaster here. A sorted list is probably a better
>  > alternative, but may be still slow... So, sets or hash-tables are
>  > better candidates. Or do I miss something?
>
>
> The problem with removeUser is that it is O(n) in the number of users
>  of a value.  Changing this operation to be O(1) [at with a very low
>  constant factor] makes it size invariant and much faster in practice.

I think, we still misunderstand each other. If you speak about
removing the element from the middle, then it is true that lists do
not do any moving of elements around and just update pointers, so they
are very fast in that. But before you can start removing, you should
first find the element to remove inside this list. removeUser is
called in my case for 8000 different keys and each time it tries to
find the element and then to remove it. So, as far as I can see, it is
 an O(n^2) time. Therefore, search time becomes a dominant factor, And
this is why a data structure with a possibility of a very fast search
is required.

>
>  >>> With all my recent changes to ScheduleDAG and instruction selector,
>  >>> the compilation time for big4.bc went down from 45-50 seconds to 6-9
>  >>> seconds!!! This is almost a 10 times performance speed-up which
>  >>> makes
>  >>> the compiler much more scaleable.
>  >>
>  >>
>  >> Nice!  Does it also help more normal cases?  That would be excellent.
>  > How do I test on "normal" cases. For small MBBs everything is so fast,
>  > that it consumes virtually no time. Can you point out some test-cases,
>  > that are big enough to be measurable, but still can be considered
>  > normal?
>
>
> MultiSource/Applications/kimwitu++ is a moderate size C++ app that is
>  a good testcase, I often use it for compile time measurements.

Thanks for the hint. I'll use this one for testing as well.

-Roman