RFC: Enable vectorization of call instructions in the loop vectorizer

[Renato Golin]

On 16 December 2013 21:05, James Molloy <james at jamesmolloy.co.uk> wrote:

> Fundamentally I think the two approaches aren't compatible, so one needs
> to be chosen as the preferred route. I actually don't mind which - to me it
> looks like Hal and Renato prefer metadata, and Nadav and Arnold prefer
> hooks, but I may have misinterpreted responses.
>

Hi James.

I disagree they're incompatible.

>From my perspective, metadata makes more sense because I (will be able to)
easily annotate functions, loops and lexical blocks with #pragma vectorize,
so I can tell which other function this one vectorizes and at which width.

However, this has three short-comings:

1. I'd have to have passed over all metadata, and saved it in a table, to
be able to know which calls can be vectorized. Normally, C rules kind of
enforce that, but that's not true with all languages.

2. It's not extensible at all, and will depend heavily on the user
annotating the code, the front-end emitting the right IR and the vectorizer
recognizing everything.

3. It'd be harder to cope with complex patterns, like in the case you said
about two vectorized functions with different argument. There is both a
semantic problem, and a data movement problem that need to be done, and the
vectorizer is NOT the right place for that, as both Nadav and Arnold said.

The call-backs, though, would make it harder to implement the #pragma
vectorize, unless I have a special call-back for metadata loops, which will
deal with all other, non-complex problems. So, in that perspective, we
could have both, with the call-back driving the metadata as a plug-in.

cheers,
--renato

PS: I need to read the patch more thoroughly, which I'll do as soon as I
send my own on the #pragma...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131216/862b0f6b/attachment.html>