[llvm-dev] mapping a returned struct (from IR) to std::vector<GenericValue>

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 21 08:26:12 PST 2016


Hi Koffie,

Casting is out, as you noted, since the struct is user defined. I think
using a pointer to the struct is your only option.

- Lang.

On Wed, Dec 30, 2015 at 12:36 AM, koffie drinker via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
>
> I'm working on a run time that allows you to run code on the fly. My
> language allows users to define custom structs.
>
> Once I have generated a func that returns a struct, I would like to map
> the function result back to a std::vector<GenericValue> to be used in the
> c++ part. For normal return types (char, ints, double) its easy to cast to
> their function pointer and execute and wrap the results.
>
> // for double f();
> auto func = (double (*f)()) engine->getFunctionAddress("f");
> double result = func();
>
> // how to do this for exampleStruct {double, double}, where example struct
> is defined by the user
> // exampleStruct f();
> // we can't do auto func = (exampleStruct (*f)())
> engine->getFunctionAddress("f");
> // since example struct is defined by the user inside the
> runtime/interpreter
> ??
>
> How can I cast a function that returns a user defined struct ? I know the
> layout of the struct, but the struct layout might be different in the IR vs
> C++? I know I could alloc memory in the func and return a ptr to a struct
> (returned as void* ), and use that as an offset to read the struct values,
> but I would like to avoid using a ptr in this case. What would be the right
> approach in ths case?
>
> I tried to look into t he executionengine::runFunction but, they are
> incomplete.
> I'm using llvm 3.7 btw.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/50666158/attachment.html>


More information about the llvm-dev mailing list