[llvm-commits] Speeding up instruction selection
Chris Lattner
clattner at apple.com
Thu Mar 6 17:52:09 PST 2008
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.
>>> 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 again Roman,
-Chris
More information about the llvm-commits
mailing list