Inlining problems again

[Iain Buclaw]

On 5 Apr 2014 21:31, "Iain Buclaw" <ibuclaw at gdcproject.org> wrote:
>
> On 5 Apr 2014 19:55, "Johannes Pfau" <nospam at example.com> wrote:
> >
> > Am Sun, 6 Apr 2014 02:51:28 +1000
> > schrieb "Daniel Murphy" <yebbliesnospam at gmail.com>:
> >
> > > "Johannes Pfau"  wrote in message
> > > news:lhp8h4$2j38$1 at digitalmars.com...
> > >
> > > > But we'd want this to work/inline nevertheless, right?:
> > > > ------------
> > > > void test(const(char)[] a)
> > > > {
> > > > }
> > > >
> > > > char[] abc;
> > > > test(abc);
> > > > ------------
> > > >
> > > > Then we still need to tell GCC that const(char)[] is a variant of
> > > > char[] or it won't inline.
> > >
> > > Can you just strip all const/immutable/etc when the type is passed to
> > > the backend?
> > >
> >
> > This would impact debug info which is also emitted by the backend. GCC
> > supports 'variants' of types which means only different qualifiers but
> > the same apart from type qualifiers. We just need to set the variant
> > information correctly (e.g. const(char)[] should be recognized as a
> > variant of char[])
>
> Right, and not having const applied to the type means that gcc might miss
an optimisation opportunity.
>
> In this case however I think that parameters declared in should not be
mapped to C-style 'const'.  The 'in' keyword is close, but something other.

FORTRAN for instance has intent attributes.

---
intent(in) - yes, pass by value, so changes of this are not reflected in
outside code.

intent(out) - pass somehow by reference, in fact a return argument

intent(inout) - pass by reference, normal in/out parameter.
---

These are interesting concepts that allows more aggressive optimisation
than using C/C++ const/ref type variants.  I think gdc should go down this
route, but I've never experimented too much round this area.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20140405/3fe234f8/attachment.html>