<p dir="ltr">On 20 Apr 2014 13:19, "Artur Skawina via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On 04/20/14 03:00, Iain Buclaw via Digitalmars-d wrote:<br>
> > On 19 April 2014 17:10, Artur Skawina via Digitalmars-d<br>
> > <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
> >> On 04/19/14 16:21, Iain Buclaw via Digitalmars-d wrote:<br>
> >>> On 19 April 2014 14:33, Artur Skawina via Digitalmars-d<br>
> >>> <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
> >>>> On 04/19/14 14:37, Iain Buclaw via Digitalmars-d wrote:<br>
> >>>>> On 19 April 2014 13:02, Artur Skawina via Digitalmars-d<br>
> >>>>> <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
> >>>>>> On 04/19/14 13:03, Iain Buclaw via Digitalmars-d wrote:<br>
> >>>>>>> On Saturday, 19 April 2014 at 10:49:22 UTC, Iain Buclaw wrote:<br>
> >>>>>>>> I'm currently testing out a GCC optimisation that allows you to set call argument flags. The current assumptions being:<br>
> >>>>>>>><br>
> >>>>>>>> in parameters => Assume no escape, no clobber (read-only).<br>
> >>>>>>>> ref parameters, classes and pointers => Assume worst case.<br>
> >>>>>>>> default => Assume no escape.<br>
> >>>>>>><br>
> >>>>>>> That should read:<br>
> >>>>>>><br>
> >>>>>>> ref parameters, inout parameters, classes and pointers.<br>
> >>>>>>><br>
> >>>>>>> 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 :)<br>
> >>>>>><br>
> >>>>>> What does "assume no escape" actually mean?<br>
> >>>>>> [The above list doesn't really make sense. W/o context, it's<br>
> >>>>>> hard to even tell why, hence the question.]<br>
><br>
> >>>> What I was wondering was things like whether that "assume no escape"<br>
> >>>> property was transitive; if /locally/ escaping was disallowed, and<br>
> >>>> to what extent. What does "assume no escape" mean at all? In your<br>
> >>>> examples you're mentioning refs together with pointers, that would<br>
> >>>> only make sense if no-escape were transitive -- but then treating all<br>
> >>>> args as no-escape would be very wrong.<br>
><br>
> >>>> I'm worried about a) invalid assumptions making it into GDC;<br>
> >>>> b) certain valid assumptions making into GDC. The latter because<br>
> >>>> it could mean that code that's incorrect, but still accepted by<br>
> >>>> the other compilers could silently break when compiled with GDC.<br>
> >>><br>
> >>> Invalid assumptions rarely make it into GDC. The testsuite is a good<br>
> >><br>
> >> AFAICT what you're proposing *is* invalid. I can't be sure because<br>
> >> it's not clear what that "no-escape" property means; that's why I<br>
> >> asked about it twice already...<br>
> >> Clearly, escaping objects reachable indirectly via function arguments<br>
> >> is perfectly fine (eg string slicing), yet you wanted to treat args as<br>
> >> no-escape by default.<br>
> ><br>
> > Not wanted - experimented. I could not think at the time a use case<br>
> > where a parameter could escape. And *I* have shown a very valid use<br>
> > case to *disprove myself*. I'm not sure of your continual persistence<br>
> > of bringing this up as this is no longer relevant to me. Other than<br>
><br>
> Several reasons. First, I did not realize that you had changed your mind.</p>
<p dir="ltr">It wouldn't be an experiment if I didn't change my mind 30 times. :)</p>
<p dir="ltr">> Second, I'm just trying to figure out what that 'assume-no-escape'<br>
> property implies. From a C based compiler I would have expected a feature<br>
> that disallowed address-of on objects, but did not affect any other<br>
> object referenced from that one (for handling C's 'register' storage class).</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">The no escape aspect leverages on what 'scope' and 'in' should be enforcing.</p>
<p dir="ltr">> Third, I'm paranoid when it comes to GDC regressions. Once upon the time<br>
> I had a working D compiler, one that was able to deliver maybe ~75% of<br>
> GCC functionality, and where the main issues were with the language and<br>
> frontend, not with the tool.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Anything that needs raising would ideally be in a bug report, as I can't keep track of issues raised in threads.</p>
<p dir="ltr">Regards<br>
Iain</p>