[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