SLP/Loop vectorizer pass ordering

[Renato Golin]

On 26 July 2014 03:05, Chandler Carruth <chandlerc at google.com> wrote:
> It would be nice for the inliner to
> have visibility into how the vectorizer will be able to pack the code of a
> function into vectors so it can more accurately estimate the size cost it
> trades off against.

A bit late to the party, and going on a tangent, but could this be
done via exposing the vectorization validation/cost models to external
passes?

When we were discussing about the interaction between Polly and the
loop vectorizer, the idea was that either would use the other's
information on legality and costs at different vector lengths
(somewhat similar to safelen metadata). Another idea was to expose the
canVectorize() method to other passes, so that you could infer some
knowledge about the end result of that being inlined or not.

I realise that this is a gamble, and inlined code can be more (or
less) easily vectorized, but at least it gives you an idea on how to
gamble. For instance, if the current vectorized cost is greater, but
very close to the scalar version, and the code reduction is 4x, it may
be profitable to inline. I'm not a big fan of gambling with
optimizations, but inlining is always a gambling, so, maybe that fits
into the model. Happy to be wrong, though.

cheers,
--renato