<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 14, 2015 at 2:59 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 13 May 2015 at 22:49, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
> There isn't really a notion of "pass" on the clang AST; the result of<br>
> parsing is considered immutable.<br>
<br>
</span>Right. What about the pre-processor?<br>
<br>
I'm not an expert on OpenMP, but would OpenMP force illegal behaviour<br>
with that pragma, or just bail if it could not prove legality?<br>
<br>
If the latter, than just adding "#pragma omp parallel loop" to all<br>
loops would work as he wants, no?<br></blockquote><div><br></div><div>I'm not sure what you mean. To put it another way, the only officially supported way to programmatically add "#pragma omp parallel loop" to a loop body is to textually rewrite the source code and re-parse.</div><div><br></div><div>Of course, all of clang's source code is there for you to look at, so for any given construct you can theoretically just imitate what is happening inside clang, but it is extremely error-prone because you need to ensure that all of the AST's invariants are maintained, with anything ranging from a crash to silent miscompilation if you don't. These invariants are not documented and probably not all consciously known.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>