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

Tian, Xinmin via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 13 10:25:18 PST 2017


>>>>If you are assuming these intrinsics will only be used to implement a specific set of annotations, with specific semantics, i'm probably with Reid on the "please use specific constructs" bandwagon.

I wouldn’t disagree on this part if these intrinsics end up with usages for a specific set of annotations.

From: Daniel Berlin [mailto:dberlin at dberlin.org]
Sent: Friday, January 13, 2017 10:01 AM
To: Tian, Xinmin <xinmin.tian at intel.com>
Cc: Mehdi Amini <mehdi.amini at apple.com>; Hal Finkel <hfinkel at anl.gov>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] IR-level Region Annotations



On Fri, Jan 13, 2017 at 9:00 AM, Tian, Xinmin via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Mehdi, thanks for good questions.

>>>>>Something isn’t clear to me about how do you preserve the validity of the region annotations since regular passes don’t know about the attached semantic?

There are some small changes we have to make in some optimizations to make sure the optimizations does not validation attached annotation semantics. 1) provide hand-shaking / query utils for optimization to know the region is parallel loop, 2) setup a proper optimization phase ordering. In our product compiler ICC, we used both approaches.

But this is very different than what you said earlier, becuase it's not minimal impact.

Also,  what you've proposed are very generic annotations, and what you are talking about here is a very specific set of ones, and their effects.

If you are assuming these intrinsics will only be used to implement a specific set of annotations, with specific semantics, i'm probably with Reid on the "please use specific constructs" bandwagon.

Otherwise, the regions could be and do anything, and the handshaking/querying has to be done everywhere, for everything, because you don't actually know what they are implementing.
Maybe my region annotation is for "don't PRE things when they have exactly 73 predecessors" regions.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170113/3de109f1/attachment.html>


More information about the llvm-dev mailing list