Missed optimisation case - internal use of STCin

[Iain Buclaw via Digitalmars-d]

On 20 Apr 2014 13:19, "Artur Skawina via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> On 04/20/14 03:00, Iain Buclaw via Digitalmars-d wrote:
> > On 19 April 2014 17:10, Artur Skawina via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >> On 04/19/14 16:21, Iain Buclaw via Digitalmars-d wrote:
> >>> On 19 April 2014 14:33, Artur Skawina via Digitalmars-d
> >>> <digitalmars-d at puremagic.com> wrote:
> >>>> On 04/19/14 14:37, Iain Buclaw via Digitalmars-d wrote:
> >>>>> On 19 April 2014 13:02, Artur Skawina via Digitalmars-d
> >>>>> <digitalmars-d at puremagic.com> wrote:
> >>>>>> On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote:
> >>>>>>> On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote:
> >>>>>>>> I'm currently testing out a GCC optimisation that allows you to
set call argument flags.  The current assumptions being:
> >>>>>>>>
> >>>>>>>> in parameters  =>  Assume no escape, no clobber (read-only).
> >>>>>>>> ref parameters, classes and pointers  =>  Assume worst case.
> >>>>>>>> default  =>  Assume no escape.
> >>>>>>>
> >>>>>>> That should read:
> >>>>>>>
> >>>>>>> ref parameters, inout parameters, classes and pointers.
> >>>>>>>
> >>>>>>> The default of assuming no escape is an experiment - I may limit
this to only scalar types, and parameters marked as 'scope'  (So long as no
one plans on deprecating it soon :)
> >>>>>>
> >>>>>> What does "assume no escape" actually mean?
> >>>>>> [The above list doesn't really make sense. W/o context, it's
> >>>>>> hard to even tell why, hence the question.]
>
> >>>> What I was wondering was things like whether that "assume no escape"
> >>>> property was transitive; if /locally/ escaping was disallowed, and
> >>>> to what extent. What does "assume no escape" mean at all? In your
> >>>> examples you're mentioning refs together with pointers, that would
> >>>> only make sense if no-escape were transitive -- but then treating all
> >>>> args as no-escape would be very wrong.
>
> >>>> I'm worried about a) invalid assumptions making it into GDC;
> >>>> b) certain valid assumptions making into GDC. The latter because
> >>>> it could mean that code that's incorrect, but still accepted by
> >>>> the other compilers could silently break when compiled with GDC.
> >>>
> >>> Invalid assumptions rarely make it into GDC.  The testsuite is a good
> >>
> >> AFAICT what you're proposing *is* invalid. I can't be sure because
> >> it's not clear what that "no-escape" property means; that's why I
> >> asked about it twice already...
> >> Clearly, escaping objects reachable indirectly via function arguments
> >> is perfectly fine (eg string slicing), yet you wanted to treat args as
> >> no-escape by default.
> >
> > Not wanted - experimented.  I could not think at the time a use case
> > where a parameter could escape.  And *I* have shown a very valid use
> > case to *disprove myself*.  I'm not sure of your continual persistence
> > of bringing this up as this is no longer relevant to me.  Other than
>
> Several reasons. First, I did not realize that you had changed your mind.

It wouldn't be an experiment if I didn't change my mind 30 times. :)

> Second, I'm just trying to figure out what that 'assume-no-escape'
> property implies. From a C based compiler I would have expected a feature
> that disallowed address-of on objects, but did not affect any other
> object referenced from that one (for handling C's 'register' storage
class).

This is an optimisation not built with a C compiler in mind, nor is it
leveraged by C/C++, so I don't think you should think of it in this way.

I was actually made aware of this particular attribute when someone spoke
to a GNU/Fortran maintainer and thought that INTENT(IN) - or at least the
no clobber aspect - could be used to improve optimisations around
'immutable' parameters. Something that gives us the one up that C-family
const could never guarantee (currently there is no difference between const
and immutable).  That is still on the table to do using this attribute
pending investigation.

The no escape aspect leverages on what 'scope' and 'in' should be enforcing.

> Third, I'm paranoid when it comes to GDC regressions. Once upon the time
> I had a working D compiler, one that was able to deliver maybe ~75% of
> GCC functionality, and where the main issues were with the language and
> frontend, not with the tool.

GCC functionality is not to be confused with C/C++ functionality.  And most
of the attributes exposed to C-family languages were nothing more an excess
baggage, ie: @artificial makes no sense when there is no inline keyword.

Anything that needs raising would ideally be in a bug report, as I can't
keep track of issues raised in threads.

Regards
Iain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140421/e1521bbc/attachment.html>