<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 13, 2015 at 12:28 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13 May 2015 at 17:53, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
> If you want the AST, you want to use libTooling or libclang to<br>
> programmatically examine the AST. The -ast-dump flag will print the AST for<br>
> debugging purposes, but it cannot be deserialized.<br>
<br>
</span>Hi Reid,<br>
<br>
Apologies for the lack of context. I sent him here. :)<br></blockquote><div><br></div><div>No problem. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Basically, he wants something similar to OpenMP (parallel loops,<br>
separate threads, multi-core CPUs) but without having to specify<br>
pragmas and command line options.<br>
<br>
My assumption is that, doing it at the IR level, it's already too<br>
late, because there's a lot of OpenMP that is Clang-based. So, if he<br>
could add a pass (possibly out-of-tree), that could identify loops and<br>
mark them with OpenMP pragmas (as they are, when the pragmas exist in<br>
the source), then he could benefit from OpenMP without requiring the<br>
users to add the pragmas to their sources or add command-line options<br>
to their Makefiles.<br>
<br>
In theory, if the toolchain he distributes has lib*omp in the right<br>
place, it should be completely transparent.<br>
<br>
Are my assumptions in the right track?<br></blockquote><div><br></div><div>I think you are on the right track, but this is going to be really hard due to the current design of OpenMP in Clang. A lot of OpenMP processing happens in Sema right now, like formation of CapturedStmts. There also isn't any alias analysis at the AST level, so separating dependent computations will be hard.</div><div><br></div><div>Is this tool intended to run automatically, or as a programmer aide to insert pragmas based on a potentially optimistic analysis? If it's a programmer aide, I wonder if you could use the Clang CFG to the dependency analysis.</div><div><br></div><div>If you want it to be just as semantics preserving as a regular optimizer pass, then you probably want to analyze the loop in IR, figure out where the loop header came from in the source code, grovel around in the AST for that source location (maybe metadata can help?), and do some kind of rewrite and recompile.</div><div><br></div><div>Another thing you might be able to do is have Clang parse all loop bodies as CapturedStmts (this will outline all loop bodies for easy parallelization), and then parallelize loops later. You'll need a way of re-inlining the loops you decide not to parallelize. OpenMP currently has some logic for this in Clang IRGen, but this is probably too early for your purposes.</div><div><br></div><div>You might *also* be able to do the outlining completely in LLVM IR time with LoopExtractor, but I assume there's a reason that OpenMP isn't using that code.</div><div><br></div><div>Hope that helps.</div></div></div></div>