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

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>

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.

----- Original Message -----
> From: "Antoine Pitrou via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Sent: Tuesday, January 19, 2016 5:54:27 PM
> Subject: Re: [llvm-dev] [RFC] A proposal for byval in a world with opaque
pointers
> 
> 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? :-)
> 
The format is documented http://llvm.org/docs/LangRef.html#data-layout but
you're not generally expected to parse the string directly. Instead,
you'd use the DataLayout class (include/llvm/IR/DataLayout.h) which contains
functions like 'uint64_t getTypeSizeInBits(Type *Ty) const;'

 -Hal
> Regards
> 
> Antoine.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory