"Johannes Pfau"  wrote in message news:lhp8h4$2j38$1@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? 

Am Sun, 6 Apr 2014 02:51:28 +1000
schrieb "Daniel Murphy" <yebbliesnospam@gmail.com>:

> "Johannes Pfau"  wrote in message news:lhp8h4$2j38$1@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[])

On 5 Apr 2014 19:55, "Johannes Pfau" <nospam@example.com> wrote:
>
> Am Sun, 6 Apr 2014 02:51:28 +1000
> schrieb "Daniel Murphy" <yebbliesnospam@gmail.com>:
>
> > "Johannes Pfau"  wrote in message news:lhp8h4$2j38$1@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.

On 5 Apr 2014 21:31, "Iain Buclaw" <ibuclaw@gdcproject.org> wrote:
>
> On 5 Apr 2014 19:55, "Johannes Pfau" <nospam@example.com> wrote:
> >
> > Am Sun, 6 Apr 2014 02:51:28 +1000
> > schrieb "Daniel Murphy" <yebbliesnospam@gmail.com>:
> >
> > > "Johannes Pfau"  wrote in message news:lhp8h4$2j38$1@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.

On 5 April 2014 20:38, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 5 Apr 2014 21:31, "Iain Buclaw" <ibuclaw@gdcproject.org> wrote:
>>
>> On 5 Apr 2014 19:55, "Johannes Pfau" <nospam@example.com> wrote:
>> >
>> > Am Sun, 6 Apr 2014 02:51:28 +1000
>> > schrieb "Daniel Murphy" <yebbliesnospam@gmail.com>:
>> >
>> > > "Johannes Pfau"  wrote in message news:lhp8h4$2j38$1@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.


See gimple.c: gimple_call_arg_flags for the middle-end detection and the implementation is roughly:

EAF_UNUSED: Unused
EAF_NOCLOBBER: Read-only
EAF_NOESCAPE: Not escaping
EAF_DIRECT: Only once dereferenced (*p, not **p)

The 'in' attribute could be mapped to 'r', meaning read-only and not escaping.

Regards
Iain.