[LLVMdev] parallel loop metadata question

[Hal Finkel]

----- Original Message -----
> From: "Jonathan Humphreys" <j-humphreys at ti.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "Tobias Grosser" <tobias at grosser.es>
> Cc: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>, llvmdev at cs.uiuc.edu
> Sent: Monday, May 5, 2014 5:09:42 PM
> Subject: RE: [LLVMdev] parallel loop metadata question
> 
> Will do.  I will write something up.
> 
> Hal, your concern below isn't so much with the proposed semantics but
> rather with the use - that optimizations must respect the loop for
> which the metadata applies, correct?

Yes, sounds right. Nevertheless, I would recommend putting such a cautionary note into the documentation itself just to make explicit an issue which might otherwise be overlooked.

 -Hal

> 
> Thanks
> Jon
> 
> -----Original Message-----
> From: Hal Finkel [mailto:hfinkel at anl.gov]
> Sent: Monday, May 05, 2014 4:00 AM
> To: Tobias Grosser
> Cc: Pekka Jääskeläinen; Humphreys, Jonathan; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] parallel loop metadata question
> 
> ----- Original Message -----
> > From: "Tobias Grosser" <tobias at grosser.es>
> > To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>, "Jonathan
> > Humphreys" <j-humphreys at ti.com>, llvmdev at cs.uiuc.edu
> > Sent: Monday, May 5, 2014 3:36:07 AM
> > Subject: Re: [LLVMdev] parallel loop metadata question
> > 
> > On 05/05/2014 10:14, Pekka Jääskeläinen wrote:
> > > On 05/02/2014 07:22 PM, Humphreys, Jonathan wrote:
> > >> Thanks for the link.  I understand your concern of caution with
> > >> metadata.
> > >> I cannot, though, imagine how the dependence relation
> > >> (independence)
> > >> of two
> > >> memory references can be affected by a third memory reference.
> > >>  If
> > >> two references are independent across loop iterations, then they
> > >> are independent, and any other load or store cannot change that.
> > >>  Right?
> > >
> > > Yes, it makes sense. I'm mostly concerned about accesses to
> > > stack,
> > > but even those at this point should remain independent. Otherwise
> > > even the current semantics might produce broken code with
> > > parallel
> > > stack accesses.
> > >
> > > However, as this is such a major semantics change to the original
> > > one, I'd like to hear more opinions on it. I suggest you create a
> > > (documentation)
> > > patch where the new semantics is articulated and request comments
> > > for it at the LLVM-commits list.
> > 
> > I agree with both. I think the extension is very reasonable and I
> > also
> > do not see a reason why this interpretation should cause troubles.
> > However, to get it right it would be good to get this throughly
> > reviewed.
> 
> I agree, I think this sounds reasonable. You'll certainly need to be
> careful, however, that the associated instruction has not been
> hoisted/sunk out of the associated loops. Even if the load is one
> that can be speculated, that does not mean that there was not a
> control dependence on the independence information itself.
> 
>  -Hal
> 
> > 
> > Tobias
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory