[llvm-commits] Speeding up instruction selection

[Chris Lattner]

On Mar 7, 2008, at 10:23 AM, Dan Gohman wrote:

> On Fri, March 7, 2008 7:26 am, Roman Levenstein wrote:
>> The most interesting thing, though, is that this implementation has
>> roughly the same performance on kimwitu (+1%), but is definitely  
>> worse
>> on the huge  big4.bc. In this one, it is about 10% worse for some
>> reason (and profiler shows suddenly that SDOperand::operator == is  
>> the
>> hottest function, when called from SDNode::hasNUsesOfValue. I have no
>> idea why... I repeated tests multiple times, but it always produces
>> the same result. With my set approach, the same function does not
>> consume any time...). I guess it is somehow related to the memory
>> access locality or something like that. Any good ideas explaining my
>> findings?
>
> Hmm, SDNode's Uses list doesn't track result numbers, so
> SDNode::hasNUsesOfValue has to iterate through every operand of
> every user of a node, calling SDOperand::operator== on each one.
> It doesn't explain why this function doesn't show up in the profile
> with your set approach, but it does seem like something that could
> be causing trouble. It would be interesting to try extending Uses to
> hold result numbers along with the users, which would make the inner
> loop of hasNUsesOfValue unnecessary. It looks like there are several
> other places in codegen where this would apply as well.

The way the machine operand and llvm ir operand classes work is that  
walking the "use" list actually walks a linked list of the operands  
that point to the values (Use or MachineOperand).  It is probably best  
for each node to have only a single use list... this means that  
walking the use list of a node would get operands of nodes that use  
any value of that node.  One way to address this is to make  
use_iterator automatically filter out uses of results that are not  
interesting.  For machine registers, the defusechain_iterator<>  
template is used to provide reg_iterator, def_iterator, and  
use_iterator.  def/use_iterator just filter out uses that aren't  
interesting for a specific iteration.

This sort of change is a major change to the way that operands and  
nodes work in the selection dag, but it should be possible to do this  
without touching all the code that uses it.  It is also quite  
important for scalability to large basic blocks and is generally a  
really worthwhile project.  If you have questions, please don't  
hesitate to ask.  I'm excited that you're tackling this!

-Chris