Displaying 4 results from an estimated 4 matches for "verifierpass".
2009 Nov 19
2
[LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()
...uce a fastcc call through the pointer.
Or, someone might rely on the function actually being located on the
returned address, and not necessarily calling it. This would break if
the address to the wrapper is returned instead.
Any thoughts on this?
On a side note: wouldn't it be nice if the VerifierPass checks that
calling conventions on calls and functions in a module match up?
Hans
2009 Nov 19
2
[LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()
...er.
>
> Or, someone might rely on the function actually being located on the
> returned address, and not necessarily calling it. This would break if
> the address to the wrapper is returned instead.
>
> Any thoughts on this?
>
> On a side note: wouldn't it be nice if the VerifierPass checks that
> calling conventions on calls and functions in a module match up?
I would prefer them to remain fastcc if I specify them as fastcc as I
actually do have 'event' handlers passed as fastcc to my C++ code
before being passed back into the JIT as another function parameter so
i...
2009 Nov 20
0
[LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()
...er.
>
> Or, someone might rely on the function actually being located on the
> returned address, and not necessarily calling it. This would break if
> the address to the wrapper is returned instead.
>
> Any thoughts on this?
>
> On a side note: wouldn't it be nice if the VerifierPass checks that
> calling conventions on calls and functions in a module match up?
>
>
> Hans
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinf...
2009 Nov 19
0
[LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()
...t rely on the function actually being located on the
> > returned address, and not necessarily calling it. This would break if
> > the address to the wrapper is returned instead.
> >
> > Any thoughts on this?
> >
> > On a side note: wouldn't it be nice if the VerifierPass checks that
> > calling conventions on calls and functions in a module match up?
>
> I would prefer them to remain fastcc if I specify them as fastcc as I
> actually do have 'event' handlers passed as fastcc to my C++ code
> before being passed back into the JIT as anothe...