[llvm-commits] Speeding up instruction selection

[Chris Lattner]

On Mar 6, 2008, at 11:10 PM, Roman Levenstein wrote:
>>> 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.

Please look at the implementation of User::setOperand() or  
MachineOperand::setReg().  When these changes the value of an operand,  
it needs to remove the current 'instruction' from the use list of the  
old value and add it to the new value.  I assure you that it is  
constant time, exactly because it doesn't have to scan the whole  
list.  It just unlinks it form the middle of the list with no search.   
This makes it very fast and scalable.

-Chris