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

[Eddy B. via llvm-dev]

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.


> (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)
>
I wholeheartedly agree: IMO, all LLVM front-ends should attach their own
typesystem information to LLVM values instead of passing bare Value*
around, or the textual equivalent, in your case.

In rustc we didn't do this from the start and it's become a complete
nightmare to work with those old parts of the codebase.


> Regards
>
> Antoine.
>
>
> _______________________________________________
> 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/20160120/bfac4229/attachment.html>