[llvm-dev] [RFC] IR-level Region Annotations

Wed Feb 1 09:42:55 PST 2017

> On Feb 1, 2017, at 9:34 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> 
> On 02/01/2017 01:29 AM, Mehdi Amini via llvm-dev wrote:
>> 
>>> On Jan 31, 2017, at 10:59 PM, Tian, Xinmin <xinmin.tian at intel.com <mailto:xinmin.tian at intel.com>> wrote:
>>> 
>>>  
>>>   <>
>>> From: mehdi.amini at apple.com <mailto:mehdi.amini at apple.com> [mailto:mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>] 
>>> Sent: Tuesday, January 31, 2017 9:03 PM
>>> To: Tian, Xinmin <xinmin.tian at intel.com <mailto:xinmin.tian at intel.com>>
>>> Cc: Sanjoy Das <sanjoy at playingwithpointers.com <mailto:sanjoy at playingwithpointers.com>>; Adve, Vikram Sadanand <vadve at illinois.edu <mailto:vadve at illinois.edu>>; llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; llvm-dev-request at lists.llvm.org <mailto:llvm-dev-request at lists.llvm.org>
>>> Subject: Re: [llvm-dev] [RFC] IR-level Region Annotations
>>>  
>>>  
>>> On Jan 31, 2017, at 7:53 PM, Tian, Xinmin <xinmin.tian at intel.com <mailto:xinmin.tian at intel.com>> wrote:
>>>  
>>> In this case, inliner is educated to add all local variables to the tag of enclosing parallel region, if there is enclosing parallel region.  
>>>  
>>>  
>>> So isn’t it a good example that shows that your intrinsic *cannot* be opaque and that IR passes need to be modified to handle not only the IR-region intrinsic but also the specific semantic of the tag?
>>>  
>>> [XT] I thought we said a number of times, there are small changes to be made. I quoted a ball park #  2000 LOC vs. 6000 LOC w.r.t changes, in one of early emails.
>> 
>> 
>> This didn’t mean that the changes were meant specifically for OpenMP. My understanding was that this proposal is for a generic "IR-level Region Annotations” mechanism, and that’s what the changes were for. Now it ends up being “let’s support OpenMP semantic without adding openmp in the intrinsic names”.
> 
> The point here is to abstract the properties about which other passes might need to know by using a set of generic intrinsics.

The fact is that I’m still not sure what these properties are, which is exactly why I’m asking for a LangRef patch.
If it has been explained in thread, then sorry I missed it, and I’d appreciate a pointer to the right post.

> The fact that you can't hoist allocas past one of these intrinsics, is nowhere close to saying that the individual optimization passes need to know anything about OpenMP, parallelism, etc. Regardless of how many LOC are in Intel's prototype, we're obviously aiming for minimal impact on the current upstream infrastructure.
> 
>> 
>> 
>>>  
>>> It seems to me that this contradicts the claim that the “tag” specific semantic does not need to be handled by the optimizer and that the intrinsic can integrate seamlessly in LLVM, which invalidates the approach (of a generic intrinsic) entirely IMO.
>>>  
>>> Maybe you never intended to claim this, but this is a hidden cost in the original RFC, and I suspect this cost has to be carefully evaluated. At this point I’m not sure it is worth discussing anything further without seeing a proper LangRef update.
>>>  
>>> [XT] All we said is to minimize cost when it is possible. The intrinsic functions is a generic for representing a directive and region, such as prefecth, unroll, omp, ….  Each instance of them will have their semantics which will be in following up RFCs
>> 
>> 
>> At this point I don’t see any advantage in having a “generic intrinsic" that has an opaque tag since all the semantic is in the tag anyway. I’d have to see what is really “generic” in the handling of it...
> 
> This is completely opposite to the point. The semantics relevant to the rest of the optimization pipeline should be in the intrinsics themselves. I've yet to see anything to suggest that we can't do that.

I’ve yet to see anything that suggest we can :)

How will it be expressed that we’re not allowed to be able to hoist an alloca? How are other constraints gonna be expressed?

> 
>> 
>> Reid identified this very early in the thread (he is a lot more perspicacious than I am) here: http://lists.llvm.org/pipermail/llvm-dev/2017-January/108914.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/108914.html>
> There are multiple levels here:
>  a) Semantics relevant to the rest of the pipeline
>  b) Semantics relevant to parallelism-specific optimizations (e.g. redundant barrier removal)
>  c) Semantics relevant to specific programming model / extension (OpenMP, OpenACC, C++ parallel algorithms, whatever)
> 
> We'd like to separate these three levels, and I believe the proposed scheme allows us to do that. Obviously, this assumes that we can indeed have a small set of intrinsics that satisfy the needs of (a). Furthermore, if we're going to use intrinsics, we need to decide whether all of the relevant semantics are reasonable to encode in intrinsics (e.g. it is reasonable to have an intrinsic past which you can't hoist an alloca, or would that need to be an instruction, etc.)

I agree with all that, and for now I’m only worried about a), which is why I asked for a LangRef update because I don’t feel I read a proper explanation there. 

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170201/503914ad/attachment.html>