llvm dev - Jan 2013 - [LLVMdev] [PATCH] parallel loop metadata

On 01/29/2013 08:22 PM, Dan Gohman wrote:
> "Ignore assumed dependencies" is shaky semantics. I haven't
seen anything
> explicitly spell out which dependencies a compiler is guaranteed to detect.
> How  can users use such a directive safely in a loop which has
dependencies?
> I understand that this is what icc's documentation says, but I'm
wondering
> if there's a real motivation for this design other than blind
compatibility.
I agree. I was puzzled by it myself until I ended up concluding that
if the set of required analysis is not defined it can be an empty set,
thus equivalent to "no dep checking at all needed":

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058727.html

Maybe the safe thing here is to rename it back to the honest
"llvm.loop.parallel" or similar and we can add a separate one for
the assumed_dep later on. This one would support the truly parallel
loops (at least OpenMP for and OpenCL WIloops) where no compiler
checking at all can be assumed by the programmer.

Any objections? Paul Redmond?

-- 
--Pekka

----- Original Message -----
> From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>
> To: "Dan Gohman" <dan433584 at gmail.com>
> Cc: "CVS Commit Messages for LLVM repository" <llvm-commits at
cs.uiuc.edu>, "LLVM Developers Mailing List"
> <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, January 29, 2013 1:42:27 PM
> Subject: Re: [PATCH] parallel loop metadata
> 
> On 01/29/2013 08:22 PM, Dan Gohman wrote:
> > "Ignore assumed dependencies" is shaky semantics. I
haven't seen
> > anything
> > explicitly spell out which dependencies a compiler is guaranteed to
> > detect.
> > How  can users use such a directive safely in a loop which has
> > dependencies?
> > I understand that this is what icc's documentation says, but
I'm
> > wondering
> > if there's a real motivation for this design other than blind
> > compatibility.
> 
> I agree. I was puzzled by it myself until I ended up concluding that
> if the set of required analysis is not defined it can be an empty
> set,
> thus equivalent to "no dep checking at all needed":
> 
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058727.html
> 
> Maybe the safe thing here is to rename it back to the honest
> "llvm.loop.parallel" or similar and we can add a separate one for
> the assumed_dep later on. This one would support the truly parallel
> loops (at least OpenMP for and OpenCL WIloops) where no compiler
> checking at all can be assumed by the programmer.
Will parallel always be synonymous with no_interiteration_dependencies? I'm
sightly worried that 'parallel' seems too much like a directive, and we
may want it to mean something else in the future.

 -Hal 
> 
> Any objections? Paul Redmond?
> 
> --
> --Pekka
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

On 01/29/2013 10:17 PM, Hal Finkel wrote:
> Will parallel always be synonymous with no_interiteration_dependencies?
I'm
> sightly worried that 'parallel' seems too much like a directive,
and we may
> want it to mean something else in the future.
I think the semantics of a "parallel loop" is:

   If my loop, I hereby state as "parallel", has loop-carried
dependencies,
   I have made a programming mistake and you, the compiler, are free to
   punish me by producing undefined results.

We can add other metadata later on. E.g. "ivdep":

   My loop might have some dependencies I know you know about, and also
   some dependencies which are impossible (for you!) to analyze. The latter
   ones you can ignore as I know those are not real dependencies, but
   please do not ignore those I know you know about :)

I think the actual "strong" parallel loop semantics is more
interesting
as it gives the most freedom and is not even a bit vague.

-- 
--Pekka

Hi Pekka,

On 2013-01-29, at 2:42 PM, Pekka Jääskeläinen wrote:
> Maybe the safe thing here is to rename it back to the honest
> "llvm.loop.parallel" or similar and we can add a separate one for
> the assumed_dep later on. This one would support the truly parallel
> loops (at least OpenMP for and OpenCL WIloops) where no compiler
> checking at all can be assumed by the programmer.
> 
> Any objections? Paul Redmond?
> 
I don't have any objections. I think the only requirement is that the
semantics are clearly defined.

Personally I think this metadata should be used to guide the vectorizer only.
I'm not sure how it will be used in the context of OpenMP or OpenCL. For
OpenMP I assume you'd add this metadata to parallel_for loops. At what point
do you insert the runtime calls? Does LLVM need to know how to target each
runtime?

paul
> -- 
> --Pekka
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

----- Original Message -----
> From: "Paul Redmond" <paul.redmond at intel.com>
> To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>
> Cc: "CVS Commit Messages for LLVM repository" <llvm-commits at
cs.uiuc.edu>, "LLVM Developers Mailing List"
> <llvmdev at cs.uiuc.edu>
> Sent: Tuesday, January 29, 2013 3:27:03 PM
> Subject: Re: [PATCH] parallel loop metadata
> 
> Hi Pekka,
> 
> On 2013-01-29, at 2:42 PM, Pekka Jääskeläinen wrote:
> 
> > Maybe the safe thing here is to rename it back to the honest
> > "llvm.loop.parallel" or similar and we can add a separate
one for
> > the assumed_dep later on. This one would support the truly parallel
> > loops (at least OpenMP for and OpenCL WIloops) where no compiler
> > checking at all can be assumed by the programmer.
> > 
> > Any objections? Paul Redmond?
> > 
> 
> I don't have any objections. I think the only requirement is that the
> semantics are clearly defined.
> 
> Personally I think this metadata should be used to guide the
> vectorizer only. I'm not sure how it will be used in the context of
> OpenMP or OpenCL. For OpenMP I assume you'd add this metadata to
> parallel_for loops. At what point do you insert the runtime calls?
> Does LLVM need to know how to target each runtime?
I think that the general direction being pursued for OpenMP is to do frontend
lowering (outlining). However, we'd still want iteration-independence
metadata to attach to the outlined loop bodies.

 -Hal
> 
> paul
> 
> > --
> > --Pekka
> > 
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

Hi,

In a personal capacity I'm quite interested in the issues of producing from
a high-level language some LLVM IR which is labelled with vectorization info
(including potentially actually reordering data in memory).

| I don't have any objections. I think the only requirement is that the
semantics are clearly defined.

I think that's very important :-)

| Personally I think this metadata should be used to guide the vectorizer only.
I'm not sure how it will be used in the context of OpenMP or OpenCL. For
OpenMP I assume you'd add this metadata to
| parallel_for loops. At what point do you insert the runtime calls? Does LLVM
need to know how to target each runtime?

I think there's two use cases: where a human programmer has written an
annotation (in some source language variant) where it represents a "best
guess" which the compiler might decide is suboptimal and choose a variant
of its own, and when the metadata has been added by a front-end compiler --
either to empirically observer the effect or because it's part of some more
extensive performance directed code-reorganisation done by the front-end --
where it really ought to be "obeyed unless impossible". In particular,
the LLVM backend is designed to be usable in routine production, which means
that certain kinds of very expensive performance optimization will be unfeasible
to be integrated. So I'd like at least a way to say "this is what I
_really_ want the vectorizer to assume" in such metadata.

Regards,
Dave

-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.