<div dir="ltr"><div><div class="gmail_signature"><div dir="ltr"><div>Johannes and Sanjoy, <br></div></div></div></div><div dir="ltr"><div><br></div>Thank you for the info, illustration and examples. <div><br></div><div>In Sanjoy's example, the current situation is that the whole parallel region is outlined as a new function by the frontend, and <span style="font-size:12.8px">intrinsic_a includes the kmp_fork_call which takes input a pointer of that function to the runtime for parallel execution. </span> Thus it prevented those exotic or evil optimization happening. The same thing for OpenMP task and cilk_spawn (cilk_spawn specifically requires a new function because of the way it handles the frame and stack in the runtime)</div><div><br></div><div>if we do not let the compiler outline (or enable inter-procedural analysis/optimization) and have a parallel region marker thing (either region metadata, instructions or others). The region could be marked 1) as if it is a sequential loop with 4 iterations and then most of the pass for sequential code would do proper optimization. We however limit us for only parallel-ignorant optimization, which is the current situation regardless of that. or 2) The region is marked as a real parallel region and develop parallel-aware passes that are independent of parallel-ignorant passes. In any approach of making the PIR, I feel safer if we can separate parallel-ignorant passes and parallel-aware one, i.e. not to introduce too much or even no changes to the current passes. </div><div><br></div><div><div>Yonghong Yan<br>Assistant Professor<br>Department of Computer Science and Engineering<br>School of Engineering and Computer Science<br>Oakland University<br>Office: EC 534<br>Phone: 248-370-4087<br>Email: <a href="mailto:yan@oakland.edu" target="_blank">yan@oakland.edu</a></div><div><a href="http://www.secs.oakland.edu/~yan" target="_blank">www.secs.oakland.edu/~yan</a></div></div><div class="gmail_extra">
<br><div class="gmail_quote">On Fri, Jan 20, 2017 at 8:32 AM, Johannes Doerfert 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 01/11, Daniel Berlin via llvm-dev wrote:<br>
> ><br>
> > def int_experimental_directive : Intrinsic<[], [llvm_metadata_ty],<br>
> > [IntrArgMemOnly],<br>
> > "llvm.experimental.directive"><wbr>;<br>
> ><br>
> > def int_experimental_dir_qual : Intrinsic<[], [llvm_metadata_ty],<br>
> > [IntrArgMemOnly],<br>
> > "llvm.experimental.dir.qual">;<br>
> ><br>
> > def int_experimental_dir_qual_opnd : Intrinsic<[],<br>
> > [llvm_metadata_ty, llvm_any_ty],<br>
> > [IntrArgMemOnly],<br>
> > "llvm.experimental.dir.qual.<wbr>opnd">;<br>
> ><br>
> > def int_experimental_dir_qual_<wbr>opndlist : Intrinsic<<br>
> > [],<br>
> > [llvm_metadata_ty, llvm_vararg_ty],<br>
> > [IntrArgMemOnly],<br>
> > "llvm.experimental.dir.qual.<wbr>opndlist">;<br>
> ><br>
> ><br>
> I'll bite.<br>
><br>
> What does argmemonly mean when the operands are metadata/?<br>
> :)<br>
><br>
> If the rest is an attempt to keep the intrinsic from being floated or<br>
> removed, i'm strongly against extending a way we already know to have<br>
> significant effect on optimization (fake memory dependence) to do this.<br>
> Particularly for something so major.<br>
<br>
</div></div>I guess that any kind of extension that does pretend to have some sort<br>
of side effect will have a significant effect on optimizations. The<br>
tricky part is to find the right representation (and side effects) that<br>
implicitly keep the semantics/invariants of parallel code preserved<br>
while allowing as much transformations as possible.<br>
<br>
[The following paragraph might be a bit abstract. If it is unclear<br>
please tell me and I will add a code example.]<br>
<br>
In the example by Sanjoy [0] we saw that "parallel regions markers" need<br>
to be a barrier for alloca movement, though we might want some<br>
transformations to "move" them nevertheless, e.g., to aggregate in<br>
parallel executed allocas outside the parallel region as a means of<br>
communication. To make a transformation like this happening but prevent<br>
the movement Sanjoy described at the same time, we probably have to<br>
educate some passes on the semantics of "parallel region markers".<br>
Alternatively, (my hope is that) if we use use known concepts (mainly<br>
dominance) to encode parts of the parallel invariants such optimizations<br>
should come at a much lower cost.<br>
<br>
Cheers,<br>
Johannes<br>
<br>
[0] <a href="http://lists.llvm.org/pipermail/llvm-dev/2017-January/109302.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/2017-<wbr>January/109302.html</a><br>
<span class="gmail-im gmail-HOEnZb"><br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">--<br>
<br>
Johannes Doerfert<br>
Researcher / PhD Student<br>
<br>
Compiler Design Lab (Prof. Hack)<br>
Saarland Informatics Campus, Germany<br>
Building E1.3, Room 4.31<br>
<br>
Tel. <a href="tel:%2B49%20%280%29681%20302-57521" value="+4968130257521">+49 (0)681 302-57521</a> : <a href="mailto:doerfert@cs.uni-saarland.de">doerfert@cs.uni-saarland.de</a><br>
Fax. <a href="tel:%2B49%20%280%29681%20302-3065" value="+496813023065">+49 (0)681 302-3065</a> : <a href="http://www.cdl.uni-saarland.de/people/doerfert" rel="noreferrer" target="_blank">http://www.cdl.uni-saarland.<wbr>de/people/doerfert</a><br>
</div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div></div>