llvm dev - Aug 2014 - [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen"

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.

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),

> 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.

cheers,
--renato

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>

> 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. 
Because other transformations might introduce recurrences that break
vectorization,
the "safelen" annotation probably should be structured more like 
llvm.mem.parallel_loop_access, and be attached to every load/store of interest.

I'm imagining that the high level interface would be a method:

	int32_t Loop::GetAnnotatedVectorSafelen()

that would do the inspection, much as Loop::IsAnnotatedParallel() currently
indicates
whether a loop is parallel.  The return value would be 0 for unannotated loops
and an upper bound on the vector width otherwise.

- Arch

On 12 August 2014 22:09, Johannes Doerfert <doerfert at
cs.uni-saarland.de> wrote:
> 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).
In our previous incarnations of such discussions, the general
consensus was that duplicating the vectorization machinery into Polly
(I believe there is already some) would be a waste of efforts. The
best course of action would be to annotate correctly (like Arch said,
on instructions not basic blocks) and get the vectorizer to do a sweep
scan on all interesting metadata and trim at the lowest common
denominator or whatever the semantics demands.

> Are these slides public?
I don't remember. Arnold, do you still have those, or some scribblings
on that area?

cheers,
--renato