[llvm-dev] [RFC] A proposal for byval in a world with opaque pointers

[Antoine Pitrou via llvm-dev]

On Wed, 20 Jan 2016 01:26:16 +0200
"Eddy B. via llvm-dev" <llvm-dev at lists.llvm.org> wrote:
> 2016-01-20 1:11 GMT+02:00 Antoine Pitrou via llvm-dev <
> llvm-dev at lists.llvm.org>:
> 
> > 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).
> >
> If you have the datalayout string, the ABI sizes become almost trivial to
> compute, the algorithms for structs are simple and I'm not aware of any
> special-cases that would complicate a front-end's computation.

For us the datalayout string is more of an implementation detail on
LLVM's side, our front-end is not normally aware of it.  As for the
algorithm, it may be trivial but is there an outline or specification
of it somewhere? :-)

Regards

Antoine.