[LLVMdev] parallel loop metadata question

Humphreys, Jonathan j-humphreys at ti.com
Mon May 5 15:09:42 PDT 2014


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?

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




More information about the llvm-dev mailing list