[LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

[Johannes Doerfert]

On 08/12, Renato Golin wrote:
> On 12 August 2014 18:49, Johannes Doerfert <doerfert at cs.uni-saarland.de> wrote:
> > I recently submitted a patch to the list [1] which would allow Polly to
> > extract the dependency distance for each analyzable loop. While the
> > distance is often not constant but parametric we would also need to
> > version the vectorized loop based on the actual runtime values.
> 
> Since this is a metadata node, we can actually add it with whatever we
> want, from an integer constant to whatever we want. But of course,
> complexity is an issue. I believe a constant is a good starting point.
Constants are particularly good since we don't need runtime checks to
utilize the information. (We might combine range information with
parametric bounds, but thats something for another day.)

> Remember that this annotation is saying that "the loop *as it is* is
> safe in a N vector", but things can change between the annotation
> (generally source code pragmas, but could be a Polly thing) and actual
> vectorization. This is a game that the user must be ready to play to
> use these advanced features and Polly has to be extremely conservative
> (since the user is *not* directly recommending safety boundaries), but
> can also allow some extra room (similar to -ffast-math, we could do
> -ffast-polly if needed),
That's true. If the vectorizer runs "directly" after Polly we are save
since the dependency distance we compute is exact, however I agree that we need
to be careful with other transformations invalidating the result.

We could actually generate (very simple) vector code ourself instead
of relying on the vectorizer. Furthermore, we could directly utilize the
heuristics and vector codegen of the vectorizer in Polly instead of
relying on the robustness of annotations. However, I think the
annotation way is easier to maintain (as we need it for source
annotations anyway).

> > However,
> > the versioning doesn't need to be done by the vectorizer but could also
> > be part of Polly (depending on whether or not the vectorizer will have
> > that capability). I admit that we would need a good heuristic in order
> > to turn this feature on as a default optimization, but I will work on
> > that in the near future too.
> 
> The original idea for vectorization annotations was to help multiple
> passes to communicate.
> 
> Initially, it was used between two passes of the vectorizer (so it
> wouldn't vectorize the same loop again) but later was used as a
> vehicle to source code pragmas. Though, the idea of Polly sharing the
> annotation space was in it from the beginning, and I think we'll come
> up with a lot more metadata than just wide/safe. Arnold had some
> slides about it.
Are these slides public?

Best regards,
  Johannes

-- 

Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.26

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140812/42bd4dae/attachment.sig>