> > > "Linthicum, Tony" <[EMAIL PROTECTED]> writes: ... > > > * What is the best way to access target level cost information? > > > > I'm sure you know that the loop code does this by generating RTL and > > asking for the cost of it (computation_cost in tree-ssa-loop-ivopts.c). > > Which should be removed (I have some patches for that, but I somehow > forgot on them because of other issues). > > Zdenek ... > > > ... determine the minimum trip count needed for the vector loop to be > > > profitable.
So, if we know the actual trip count to be more than this minimum trip count (mtc), we'll abandon the effort to vectorize. And if we don't know the actual trip count, we can ask at runtime if it is larger than mtc. We already ask at runtime if the actual trip count is larger than the vectorization factor, if we don't know the actual trip count at compile time. In such (predominant?) cases the vectorized loop gets versioned, keeping its original scalar version and introducing another, vector version, with this runtime guard choosing between the two. (This is also used to check if potentially aliased pointers overlap, or to check alignment constraints.) If we version the loop, we can update the threshold of this guard at a later stage, when the cost of each version becomes more apparent (RTL). So if we don't want to generate RTL just for the sake of computing its cost, we can wait until it is eventually generated (and optimized) and plug its cost back where we need it. One disadvantage is that we're not saving compile-time (and probably produce worse code) if the mtc turns out to be greater than a known trip count, or greater than any conceivable trip count. There are ways to try and cope with this disadvantage, and there are additional disadvantages... BTW, we had a simple cost model for the modulo scheduler, which turned out to be overly conservative (fourth in-progress item on http://gcc.gnu.org/wiki/SwingModuloScheduling). Ayal.
