Missed optimisation case - internal use of STCin

Mon Apr 21 02:03:03 PDT 2014

On 21 Apr 2014 09:56, "Iain Buclaw" <ibuclaw at gdcproject.org> wrote:
>
> 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.
>

As for the original topic.

STCin is an attribute ignored by the compiler (only talking about gdc) -
which is a shame because marking parameters as 'in' I see is still
encouraged.  And I would assume the same is true also for dmd and ldc,
otherwise someone would have noticed this bug by now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140421/ba9791c9/attachment-0001.html>