[LLVMdev] How to extend llvm IR and frontend?

[Jeff Kunkel]

I would think clang would be more appropriate for adding a c-declaration
descriptor. However, assuming that no translation down to llvm exists, you
would need to create the information as either metadata (preferred) or as a
new type (ugly and time consuming). If you can keep it as metadata, then
some later passes may gather that meta-data and execute properly. A new type
requires much in the way of hacking other passes to inform them what to do
upon seeing the new type.

- My 2 cents,
Jeff Kunkel

On Fri, Jan 21, 2011 at 10:32 AM, Aaron Myles Landwehr <snaphat at gmail.com>wrote:

> Hi all,
>
> Hypothetically, suppose I have a generic system with multiple address
> spaces such that each address space is accessed using different
> instructions.
>
> Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of
> c variables and function return types such that the following would be
> valid:
>
> foo void* a;
> foo void* somefunc(){...}
> bar int b;
> int somefunc2(bar int*){...}
>
> Furthermore, if I wanted this keyword to be added as part of the LLVM IR in
> some manner such that the during the translation of LLVM IR to some target
> machine ASM it could be used to switch which address spaces are used (e.g.
> if I specify one of the keywords, I get some instruction or group of
> instructions to access a certain address space), what would be the
> correct/easiest place(s) to add this functionality, and would there be
> existing code that does something similar that can be used as a starting
> point?
>
> More Info: suppose this uses clang as a frontend.
>
> Thanks,
> Aaron Landwehr
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110121/78b84a85/attachment.html>