[llvm-dev] [RFC] A proposal for byval in a world with opaque pointers
Antoine Pitrou via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 19 15:11:27 PST 2016
On Wed, 20 Jan 2016 00:47:56 +0200
"Eddy B. via llvm-dev" <llvm-dev at lists.llvm.org> wrote:
>
> I would love to know your thoughts on this, and more specifically:
> Which of the 3 (byval(T), byval(N) and byval + dereferenceable + align)
> do you think would provide the easiest transition path for front-ends?
We (llvmlite and Numba) don't use byval specifically but, were we to use
it, I think byval(T) would by far be the easiest for us. By contrast,
computing ABI sizes is a bit of a PITA due to llvmlite's architecture
(llvmlite's IR generation side doesn't call into LLVM at all, it
generates textual IR in pure Python).
(as a matter of fact, I plan to keep typed pointers in llvmlite,
because they provide invaluable help discovering bugs early rather than
late - i.e. giving a proper error rather than crashing mysteriously)
Regards
Antoine.
More information about the llvm-dev
mailing list