[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