On Feb 12, 2013, at 1:41 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote:> Hi, > > Here it is, just synched against the latest LLVM trunk. Shall I commit this > now?LGTM. Please commit.> After committing, it could be worth some planning what is the best way to > provide an easy to use mechanism to "refresh" the parallel loop mem > access metadata (llvm.mem.parallel_loop_access) after optimizations that do not > render the loop to a serial one. Some kind of helper function should be > added to make it as easy as possible. > > E.g., if the inliner inlines a call to a parallel loop's body, how can it > easily and robustly refresh the parallel loop metadata to the inlined function? > It needs to annotate only the new memory instructions in the loop with the > parallel mem metadata, but not any of the old ones as there might > have been a parallel-loop-unaware pass before that has added mem instructions > without the metadata. Thus, we cannot just blindly refresh the whole parallel > loop with the parallel mem access metadata after the pass finishes. >Lets wait and see if this is a real problem before we change lots of passes in the compiler.> On 02/12/2013 08:12 PM, Nadav Rotem wrote: >> >> On Feb 12, 2013, at 9:02 AM, Tobias Grosser <tobias at grosser.es> wrote: >> >>> On 02/12/2013 05:54 PM, Nadav Rotem wrote: >>>> >>>>> I have the feeling option 2) does not work for you, but I don't yet >>>>> understand your reasons. >>>> >>>> My inclination to prefer #1 is due to its simplicity. But, if #1 does not >>>> work because it creates a correctness problems then #2 is the only option >>>> that is left on the table. >>> >>> Unfortunately. :-( >>> >>> Does your reply mean you agree that option 2) should be taken? >> >> Yes. I think that there is a consensus that this is the right approach. >> >>> In case you do, how should we proceed? Should Pekka submit his patch for a >>> final pre-commit review? >> >> I think so. Pekka's patch from Jan 31st looks good to me. The is bug in the >> metadata handling in the vectorizer that we don't check that the load/store >> annotation matches the loop metadata. >> >>> >>> If option 2) is OK, Paul could also try to produce this metadate from his >>> #pragma ivdep parser. >>> >> >> That would be wonderful. >> >> Thanks, Nadav >> > > > -- > --Pekka > > <llvm-3.3-parallel-loop-metadata.patch>
On 12 February 2013 21:59, Nadav Rotem <nrotem at apple.com> wrote:> Lets wait and see if this is a real problem before we change lots of > passes in the compiler. >+1 Looks good for me too. --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130212/7e078895/attachment.html>
On 02/12/2013 11:59 PM, Nadav Rotem wrote:> LGTM. Please commit.Committed in r175060. Thanks all for the feedback. Yes, let's see what evolves as the best way to keep the metadata updated after "non-serializing optimizations". This metadata is produced by pocl for the "work-item loops" in the work group functions. Perhaps the #pragma ivdep support in Clang is going to be the next producer. -- --Pekka
Hi, Is it fair to say that we require loops to be in canonical form with a single backedge to which we attach llvm.loop.parallel? Or is it the frontend's responsibility to attach the metadata to each backedge? Looking at the patch there is an assumption that there is a single loop latch. Clang, for example, generates loops with multiple backedges (e.g, while with continue.) How does pocl deal with this? paul On 2013-02-13, at 1:13 PM, Pekka Jääskeläinen wrote:> On 02/12/2013 11:59 PM, Nadav Rotem wrote: >> LGTM. Please commit. > > Committed in r175060. Thanks all for the feedback. > > Yes, let's see what evolves as the best way to keep the metadata > updated after "non-serializing optimizations". > > This metadata is produced by pocl for the "work-item loops" in > the work group functions. Perhaps the #pragma ivdep support in Clang is > going to be the next producer. > > -- > --Pekka > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
The documentation isn't clear about the uniqueness of loop identifier
metadata. Should every loop have a unique loop id metadata? I think the answer
is yes but I'm not sure how this can be enforced.
A particular case I'm thinking of is something like:
void foo() {
for (...) {
}
}
void bar() {
for (...) {
foo();
}
}
If the loops in foo and bar have the same loop id metadata and foo is inlined
then you have two loops with the same id.
paul
On 2013-02-13, at 1:13 PM, Pekka Jääskeläinen wrote:
> On 02/12/2013 11:59 PM, Nadav Rotem wrote:
>> LGTM. Please commit.
>
> Committed in r175060. Thanks all for the feedback.
>
> Yes, let's see what evolves as the best way to keep the metadata
> updated after "non-serializing optimizations".
>
> This metadata is produced by pocl for the "work-item loops" in
> the work group functions. Perhaps the #pragma ivdep support in Clang is
> going to be the next producer.
>
> --
> --Pekka
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev