<div dir="ltr"><div>Hi William,</div><div><br></div><div>Currently, LLVM lowers parallel constructs of OpenMP at the front-end level to runtime calls; although simple, this ad-hoc solution prevents high-level reasoning about parallel languages while possibly introducing semantic inconsistencies in existing sequential program analyses. Worse, users implicitly rely upon the lack of interprocedural analyses within many compilers to preserve the semantics of programs even in the presence of code optimizations. </div><div><br></div><div>As part of my PhD work, I worked on introducing a parallel intermediate representation extension for parallel compilers which I called <i>SPIRE</i>. SPIRE was successfully applied to automatically parallelize sequential programs within the PIPS source to source compiler. (Here is a link to my PhD thesis: <a href="https://tel.archives-ouvertes.fr/pastel-00935483/document">https://tel.archives-ouvertes.fr/pastel-00935483/document</a>).</div><div><br></div><div>As part of my Postdoc work at University of Houston, I am currently applying SPIRE to LLVM in order to optimize PGAS languages, specifically OpenSHMEM. The idea is to be able to recognize OpenSHMEM constructs and represent them explicitly in the LLVM IR using SPIRE to take advantage of sequential optimizations offered by LLVM. The ultimate goal is to develop new parallel optimizations based on SPIRE(LLVM IR). The tricky part here is to prove that the enabled optimizations will generate correct codes. I am using SPIRE formal operational semantics I developed to prove the correctness of optimizations performed on parallel programs.</div><div><br></div><div>I can send you a submitted paper regarding this work on LLVM if you are interested.</div><div><br></div><div>Best,</div><div><br></div><div><br></div>-- <br><div class="gmail_signature">Dounia KHALDI<br>Postdoctoral Fellow<br>University of Houston<br>Department of Computer Science<br>501 Philip G. Hoffman Hall<br>Houston, TX  77204-3010</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 9, 2015 at 10:58 AM, William Moses <span dir="ltr"><<a href="mailto:wmoses@csail.mit.edu" target="_blank">wmoses@csail.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm part of a research group at MIT looking to create an extension of LLVM that inherently allows one to nicely code a parallel loop.<div><br></div><div>Most parallel frameworks tend to take the body of a parallel loop and stick it inside of a function for the parallel runtime to call when appropriate. However, this makes optimizations significantly more difficult as most compiler optimizations tend to be intraprocedural. The goal of this parallel IR is to allow LLVM to more easily optimize parallel code -- which often gets the short end of the optimization stick.</div><div><br></div><div>Long story short: I was wondering if anyone in the LLVM community has already begun a similar project or knows of something that begins to accomplish this.</div><div><br></div><div>Additionally, does anyone who has worked with parallelism in LLVM have any specific comments or suggestions regarding this project.</div><div><br></div><div>Sincerely,</div><div>William Moses</div><div>MIT Computer Science and Artificial Intelligence Laboratory</div><div><br></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Dounia KHALDI<br>Postdoctoral Fellow<br>University of Houston<br>Department of Computer Science<br>501 Philip G. Hoffman Hall<br>Houston, TX  77204-3010</div>
</div>