[LLVMdev] parallel loop metadata simplification

[Hal Finkel]

----- Original Message -----
> From: "Paul Redmond" <paul.redmond at intel.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu>
> Sent: Friday, March 1, 2013 10:06:51 AM
> Subject: Re: [LLVMdev] parallel loop metadata simplification
> 
> Hi Hal,
> 
> On 2013-02-28, at 9:33 PM, Hal Finkel wrote:
> 
> > ----- Original Message -----
> >> From: "Paul Redmond" <paul.redmond at intel.com>
> >> To: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu>
> >> Sent: Thursday, February 28, 2013 1:30:57 PM
> >> Subject: [LLVMdev] parallel loop metadata simplification
> >> 
> >> Hi,
> >> 
> >> I've been working on clang codegen for #pragma ivdep and creating
> >> the
> >> llvm.mem.parallel_loop_access metadata seems quite difficult. The
> >> main problem is that there are so many places where loads and
> >> stores
> >> are created and all of them need to be changed when emitting a
> >> parallel loop. Note that creating llvm.loop.parallel is not a
> >> problem.
> >> 
> >> One option is to modify IRBuilder to enable attaching the metadata
> >> for loads and stores but that seems like a huge hack.
> > 
> > Can you please explain why this is a bad option? To be honest, this
> > is what I expected you to do. The IRBuilder sits on top of all of
> > the loads and stores, and seems like the perfect place to keep
> > state for something that affects "all" loads and stores in some
> > code region. In addition, putting this in IRBuilder should also
> > make it easier to use this feature from other frontends.
> 
> One concern I have is that the llvm.mem.parallel_loop_access can
> refer to nested loops. Is it possible that instructions in the same
> loop require different metadatas (one is parallel in both inner and
> outer loop and another is only parallel in the inner loop?) This is
> a more general problem I think but the IRBuilder would only be
> useful for brute force adding the same metadata to all instructions
> with mayReadOrWriteMemory().

Well, it would be more complicated than that anyway because you specifically don't want to tag the loads and stores to the local alloca'd variable storage locations, only the "explicit" memory references. I think an extra boolean parameter to CreateLoad, etc. could take care of those? Nevertheless, IRBuilder could keep a stack of parallel loops to handle nested cases, right?

 -Hal

> 
> Thoughts?
> 
> paul
> 
> > 
> > -Hal
> > 
> >> 
> >> I'd like to reopen the discussion on requiring the
> >> llvm.mem.parallel_loop_access metadata. I understand the reason
> >> for
> >> the metadata is to protect against transformations that may
> >> introduce unsafe parallel memory accesses (the reg2mem example.)
> >> I'm
> >> wondering if perhaps we can make the metadata more user-friendly
> >> by
> >> providing a single loop metadata which can be expanded into
> >> "safer"
> >> metadata as required. Specifically a loop pass could be added that
> >> expands llvm.loop.parallel into llvm.loop.parallel_protected +
> >> llvm.mem.parallel_loop_access.
> >> 
> >> Perhaps there are simpler options I've overlooked?
> >> 
> >> paul
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >> 
> 
>