April 05, 2014 Re: Inlining problems again | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | "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? |
April 05, 2014 Re: Inlining problems again | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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[])
|
April 05, 2014 Re: Inlining problems again | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau Attachments:
| 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.
|
April 05, 2014 Re: Inlining problems again | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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. |
April 05, 2014 Re: Inlining problems again | ||||
---|---|---|---|---|
| ||||
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.
|
Copyright © 1999-2021 by the D Language Foundation