[llvm-commits] Speeding up instruction selection

[Dan Gohman]

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.

Dan