[LLVMdev] How to implement list in llvm

[B B]

Thank you very much for your answers. As you said, we decided too to use
std::vector<void*>. Maybe in the future we'll try to make our own structure
from scratch but for now this one is OK.

Best,
blackbox dev team

2013/4/19 Cristianno Martins <cristiannomartins at gmail.com>

>  Oh, ok, sorry but only now I understood your list will be used by the
> programmers functions on his code, and not on your pass code for llvm while
> your pass is being compiled XD
>
> Ok, once I had a similar problem, and I resolved it by creating a mini API
> in C++ with some classes that encapsulated lists of integer, floating point
> or pointer types (I actually needed three different classes for those three
> types). Those are not that hard to write, and I guess mine would not be
> very welcome to share because I had a very specific implementation (I
> wanted something with a queue behavior, and I was working with "many
> producers -> one consumer" strategy).
>
> So all I had to do was insert the right calls on the functions being
> transformed by my pass, and that was it.
>
> Cheers,
>
> --
> Cristianno Martins
> PhD Candidate in Computer Science
> University of Campinas
> cmartins at ic.unicamp.br
>
> On Friday, 19 de April de 2013 at 12:19, Tim Northover wrote:
>
> In my compiler I want to give user a list of user defined classes. I tried
> to use generated bitcode of my own wrapper of std::vector, but there is no
> possibility to generate bitcode of template, so I finally build it with
> std::vector<void*>.
>
>
> Does this mean you wrote a wrapper around std::vector, generated LLVM
> IR for it, and then inserted this IR into your compiled code in some
> manner?
>
> Do you know about any better solutions how to build such
> a type with llvm? Maybe there is a llvm built in type that is better choice
> than external c++ wrapper?
>
>
> If I understand what you're doing, there's no generic LLVM
> implementation of any complex datatypes for front-ends to use. Each
> one is expected to implement its own requirements.
>
> In principle, some kind of library could be developed, of course.
>
> Tim
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130424/a20967b2/attachment.html>