[llvm-commits] [llvm] r166865 - /llvm/trunk/lib/Transforms/Vectorize/BBVectorize.cpp

[David Tweed]

On Oct 26, 2012, at 10:08 PM, Hal Finkel <hfinkel at anl.gov> wrote:





To be fair, I think we expected this. I see two general solutions:
1. Cover all such cases with target hooks

 

This is possible. 





2. When the cost of some operation is requested, actually compile it (make a
small selection DAG and run instruction selection), and then use the result
(we could just count the number of machine instructions, for example). We'd
need to cache the results for this to be practical.

 

I don't think that this is a good approach. The compile time for this kind
of mechanism would be very high. 

 

We can build an off-line tool that would compile IR to assembly. We can use
this (off-line) tool to generate cost-tables. 

 

I've been thinking of looking at something along those lines (obviously
partly ARM specific, but large bits of the code would be target
independent). One of the other issues is that, from experience on x86, using
the TSC to time pieces of code you really need to be running a noticeable
number of "iterations" not just because of the TSC not serialising, but
because you're really trying to estimate the cost of an instruction in the
context of lots of executions (eg, it might be stored in DecoderQueue for
tight loops and not need decoding ,etc). All this suggests it's ill-suited
to be running at run-time. (Note this is for estimating the cost of
individual instructions: trying differently machine-code variants on your
entire function kernel at run-time might be significant enough that the cost
is worth it.) The obvious issue is that IR might be compiled differently in
the off-line system (particularly if it doesn't have surrounding
instructions to affect decisions) compared to when it's compiled in-situ.
Not sure there is a good solution for that.

 

Cheers,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121029/6666dd1f/attachment.html>