llvm dev - Oct 2013 - [LLVMdev] Attach state from clang to LLVM

I'd like to evaluate a couple of extensions to a C-like language, and I was
hoping to use Clang and LLVM to do that.

I ran into a couple of issues, and I'd appreciate if you could advise on the
best practices to address them.

 

-1- I modified Clang parser to accept the extension syntax (say a property
for a function, statement, parameter, or variable), 

but how do I propagate the state from Clang to LLVM IR?

I need the state to be "persistent"; i.e., IR assembly or bitcode
should
contain it, and IR reader should get it into memory when deserializing.

How do I do this without changing LLVM IR, IR readers and writers? Is there
any way to attach "custom" state to IR classes?

I noticed that there are annotations and metadata mechanisms. Should I use
one of these, which one, or there are better ways?

 

-2- I need to keep this custom state (per functions, instruction, operand,
variable) in LLVM IR for my optimization passes.

In addition, I'd like to leverage a few existing optimizations: the extra
state will not interfere with these, but I do not want to "educate"
the
existing optimizations to ignore it (I still need it preserved though).

What is the best way to do this? Should I subclass existing IR classes, use
metadata, use annotations, or do it somehow else?

I'll need to query and modify extra state frequently, so the mechanism
should be performant.

Some of the state should also make it to the persistent IR forms.

 

Thanks in advance,

Alex

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131023/b5678e2f/attachment.html>

Metadata will do exactly this, but the cost is that because you didn't
teach the optimizers about your metadata, they are free to drop it on the
floor whenever they optimize.

If you want something persistent, consider adding your own intrinsics or
function calls that are appropriately annotated as readnone etc and hope
they don't affect optimization too much.


On Wed, Oct 23, 2013 at 12:29 PM, Alejandro Jimenez Martinez <
whilealex at gmail.com> wrote:
> I’d like to evaluate a couple of extensions to a C-like language, and I
> was hoping to use Clang and LLVM to do that.****
>
> I ran into a couple of issues, and I’d appreciate if you could advise on
> the best practices to address them.****
>
> ** **
>
> -1- I modified Clang parser to accept the extension syntax (say a property
> for a function, statement, parameter, or variable), ****
>
> but how do I propagate the state from Clang to LLVM IR?****
>
> I need the state to be “persistent”; i.e., IR assembly or bitcode should
> contain it, and IR reader should get it into memory when deserializing.***
> *
>
> How do I do this without changing LLVM IR, IR readers and writers? Is
> there any way to attach “custom” state to IR classes?****
>
> I noticed that there are annotations and metadata mechanisms. Should I use
> one of these, which one, or there are better ways?****
>
> ** **
>
> -2- I need to keep this custom state (per functions, instruction, operand,
> variable) in LLVM IR for my optimization passes.****
>
> In addition, I’d like to leverage a few existing optimizations: the extra
> state will not interfere with these, but I do not want to “educate” the
> existing optimizations to ignore it (I still need it preserved though).***
> *
>
> What is the best way to do this? Should I subclass existing IR classes,
> use metadata, use annotations, or do it somehow else?****
>
> I’ll need to query and modify extra state frequently, so the mechanism
> should be performant.****
>
> Some of the state should also make it to the persistent IR forms.****
>
> ** **
>
> Thanks in advance,****
>
> Alex****
>
> ** **
>
> _______________________________________________
> 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/llvm-dev/attachments/20131023/358434b3/attachment.html>