<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 13, 2017 at 9:00 AM, Tian, Xinmin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mehdi, thanks for good questions.<br>
<span><br>
>>>>>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?<br>
<br>
</span>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.<br>
<span><br></span></blockquote><div><br></div><div>But this is very different than what you said earlier, becuase it's not minimal impact.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>Maybe my region annotation is for "don't PRE things when they have exactly 73 predecessors" regions.</div><div><br></div><div><br></div></div></div></div>