Inlining problems again

[Iain Buclaw]

On 5 April 2014 20:38, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
> 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.


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.