[cfe-dev] Mutable AST -- Advice Needed --

[David Blaikie]

On Tue, May 28, 2013 at 10:57 AM, steveneliuk <s.eliuk at samsung.com> wrote:

> Hello,
>
> The WebCL Working Group (WG) is requesting input from experienced
> Clang/LLVM
> developers and contributors concerning AST mutation.
>
> A little background,
>
> WebCL exposes parallel processing to the web. Specifically, WebCL allows
> web
> applications to utilize GPU\s and multi-core CPU\s directly from the
> web-browser. This is about the least verbose description I could produce,
> more information can be found through the following  link
> <http://www.khronos.org/webcl/>  .
> http://www.khronos.org/webcl/
>
> There is a tight relationship between WebCL and OpenCL because WebCL
> employs
> /orchestrated/ OpenCL-kernels to enable parallel processing on parallel
> devices. The /orchestrated/ kernels provide a level of security/projection
> that is not inherent/needed in OpenCL.
>
>
> Typically, a web-developer produces a kernel and WebCL uses a Validator to
> /orchestrate/ the kernel. The validator performs various checks such as
> memory initialization, validity of pointers, static/dynamic analysis, etc
> and outputs the new kernel that is web-safe.
>

If I'm understanding you correctly you're proposing some kind of
source-to-source translation, yes?

If so, have you considered/examined the Tooling infrastructure and AST
matchers? These have been used to rewrite C++ code in various ways, but
without AST mutation. The general desire is to find the relevant source you
want to modify & then rewrite it, rather than attempting to mutate the AST
in memory & then generate new source from the AST itself.


> One of the proposed directions of development is based on Clang, and going
> against the grain, with a mutable AST. We understand the AST in Clang is
> fundamentally treated as immutable and we respect this design choice. The
> goal of the WebCL Validator does not rely on a later stage coupling with
> LLVM or later stages of compilation where the modified AST could become
> unstable/problematic.
>
> Given the above information, could those with experience and expertise
> please provide feedback on the proposed implementation? We are curious the
> pitfalls of modifying the AST. Eventually, if the code is stable and meets
> the requirements of Clang we would like to upstream/contribute the code,
> but
> this would be in the distant future.
>
> There is a bug open concerning the WebCL Validator development effort that
> can be accessed through the following  link
> <https://www.khronos.org/bugzilla/show_bug.cgi?id=875>  ,
> https://www.khronos.org/bugzilla/show_bug.cgi?id=875
>
> Thank you on behalf of the WebCL WG for considering our request,
>
> Kindest Regards,
>
>
>
> --
> View this message in context:
> http://clang-developers.42468.n3.nabble.com/Mutable-AST-Advice-Needed-tp4032339.html
> Sent from the Clang Developers mailing list archive at Nabble.com.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130528/fc1ded48/attachment.html>