On Tue, May 28, 2013 at 10:57 AM, steveneliuk <span dir="ltr"><<a href="mailto:s.eliuk@samsung.com" target="_blank">s.eliuk@samsung.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
The WebCL Working Group (WG) is requesting input from experienced Clang/LLVM<br>
developers and contributors concerning AST mutation.<br>
<br>
A little background,<br>
<br>
WebCL exposes parallel processing to the web. Specifically, WebCL allows web<br>
applications to utilize GPU\s and multi-core CPU\s directly from the<br>
web-browser. This is about the least verbose description I could produce,<br>
more information can be found through the following  link<br>
<<a href="http://www.khronos.org/webcl/" target="_blank">http://www.khronos.org/webcl/</a>>  .<br>
<a href="http://www.khronos.org/webcl/" target="_blank">http://www.khronos.org/webcl/</a><br>
<br>
There is a tight relationship between WebCL and OpenCL because WebCL employs<br>
/orchestrated/ OpenCL-kernels to enable parallel processing on parallel<br>
devices. The /orchestrated/ kernels provide a level of security/projection<br>
that is not inherent/needed in OpenCL.<br>
<br>
<br>
Typically, a web-developer produces a kernel and WebCL uses a Validator to<br>
/orchestrate/ the kernel. The validator performs various checks such as<br>
memory initialization, validity of pointers, static/dynamic analysis, etc<br>
and outputs the new kernel that is web-safe.<br>
<br>
One of the proposed directions of development is based on Clang, and going<br>
against the grain, with a mutable AST. We understand the AST in Clang is<br>
fundamentally treated as immutable and we respect this design choice. The<br>
goal of the WebCL Validator does not rely on a later stage coupling with<br>
LLVM or later stages of compilation where the modified AST could become<br>
unstable/problematic.<br>
<br>
Given the above information, could those with experience and expertise<br>
please provide feedback on the proposed implementation? We are curious the<br>
pitfalls of modifying the AST. Eventually, if the code is stable and meets<br>
the requirements of Clang we would like to upstream/contribute the code, but<br>
this would be in the distant future.<br>
<br>
There is a bug open concerning the WebCL Validator development effort that<br>
can be accessed through the following  link<br>
<<a href="https://www.khronos.org/bugzilla/show_bug.cgi?id=875" target="_blank">https://www.khronos.org/bugzilla/show_bug.cgi?id=875</a>>  ,<br>
<a href="https://www.khronos.org/bugzilla/show_bug.cgi?id=875" target="_blank">https://www.khronos.org/bugzilla/show_bug.cgi?id=875</a><br>
<br>
Thank you on behalf of the WebCL WG for considering our request,</blockquote><div><br></div><div>It's unclear to me from the above description what you actually want to do with Clang.</div><div><br></div><div>Are you actually trying to perform source-to-source translation or validation or something else?</div>
<div>If it's source-to-source translation, is the output intended to be human-maintainable or only as the input to other tools?</div><div>If it's a validator, why do you want a mutable AST?</div></div>