[LLVMdev] Regarding BOF: Vectorization in LLVM

[Renato Golin]

On 6 November 2012 18:54, Nadav Rotem <nrotem at apple.com> wrote:
> Also, I should mention that I would like us to implement the ICC
> vectorization intrinsics [1].

I think it would be good to use the maximum information we need from
the developer for vectorization, but I'm not sure this would be the
first item on my agenda. ;)

Though, I'm not against it now or any time. GCC supports it, doesn't it?


> Maybe we can start the discussion by deciding if we want to use metadata or
> intrinsics.

I had a good deal of thought about that and couldn't think of any but
the most naive vectorizations working without it. Not necessarily
metadata, but some kind of annotation, even if it would be discarded
after every pass.

Since a lot of the assumptions require you to probe different types of
relationship between variables and code, and since probes can normally
be expensive, memoizing intermediate state as metadata is important to
be efficient. As discussing earlier, we probably need IR versioning,
which is expensive, and the more we can save of these failed attempts
(that is still relevant), the better.

It'll not be easy to determine what stays and what can't, and how to
organize it in a way that is both simple and expressive, but if we can
have it so that other passes (such as Polly) can use it or the front
ends produce it (like #ivdep or #openmp). How does the other pragmas
that annotate code work?

The proposed openmp implementation works by wrapping code around
calling intrinsics. This is another way to annotate IR, but one that
might suffer a lot from code motion, inlining, etc. But at least, if
#openmp say that loop is private, even if it runs on a separate openMP
thread, we can still maybe vectorize it more efficiently (can't we?).

Just throwing ideas late at night, I might have said a load of carps...

--
cheers,
--renato

http://systemcall.org/