On 21 Apr 2014 09:56, "Iain Buclaw" <[email protected]> wrote: > > On 20 Apr 2014 13:19, "Artur Skawina via Digitalmars-d" < [email protected]> wrote: > > > > On 04/20/14 03:00, Iain Buclaw via Digitalmars-d wrote: > > > On 19 April 2014 17:10, Artur Skawina via Digitalmars-d > > > <[email protected]> wrote: > > >> On 04/19/14 16:21, Iain Buclaw via Digitalmars-d wrote: > > >>> On 19 April 2014 14:33, Artur Skawina via Digitalmars-d > > >>> <[email protected]> wrote: > > >>>> On 04/19/14 14:37, Iain Buclaw via Digitalmars-d wrote: > > >>>>> On 19 April 2014 13:02, Artur Skawina via Digitalmars-d > > >>>>> <[email protected]> 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.
