<p dir="ltr">On 20 April 2014 13:19, Artur Skawina via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<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.<br>
> 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).<br>
> 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. This was a few years ago, after you'd fixed<br>
> the many small problems I had run into. The type of those issues made it<br>
> very clear that I was the only one that was trying to really use GDC.<br>
> Unfortunately what happened then was that things started to get worse, and<br>
> by worse I mean "unusable"; GDC ceased to be able to deliver functionality<br>
> and performance that was in the same league as GCC C/C++. LTO stopped<br>
> working (which is not only crucial for a language w/o macros and low-level<br>
> control, but was useful as a work-around for tool issues, like the lack<br>
> of cross module inlining).</p>
<p dir="ltr">I have not seen this, infact the opposite.</p>
<p dir="ltr">As for speed of runtime.  Many of the optimisations that were removed in the last year have been found when porting to architectures that are less forgiving than x86.</p>
<p dir="ltr">I still don't what's up with LTO. It's not easy to debug, and fails in a way that doesn't seem to suggest a front-end problem (it chokes when reading LTO information written by itself).</p>
<p dir="ltr">> The accepted language changed in a way that<br>
> was completely backward incompatible and would have required an extra<br>
> preprocessing step (pragma-attributes were removed and became hard<br>
> errors). GCC attributes became inaccessible; things like @pure, @malloc,<br>
> @ifunc, @align, @cold, @regparm all used to work, but now didn't. @inline,<br>
> @noinline and @flatten were added back as /true/ D-style attributes later,<br>
> and seem to work great.</p>
<p dir="ltr">Many of these attributes to which need a good reason to be hashed out.  Originally my intention was to only expose those that are impossible to infer otherwise in D through existing language features.</p>
<p dir="ltr">> Thanks for exposing those, but my concern is that<br>
> dealing with them one-by-one does not scale - that's why I haven't filed<br>
> any bug reports wrt the other ones.</p>
<p dir="ltr">They were exposed one-by-one before too. The entire source of routines was pretty much a copy-paste job from c-common.c. It has been suggested by the gcc maintainers to put those attributes into a more common area that can be shared between C/C++/ObjC and D - but there were too many subtle differences to make that work at all.  So instead I lopped of the head of the problem. The same as D iasm support, which was similarly dropped completely.</p>

<p dir="ltr">> Your work on getting D support merged<br>
> into GCC is critically important for the survival of the language; things<br>
> that are merely optimizations can happen later, or will be mostly irrelevant<br>
> (if the merge never happens).<br>
> But the situation right now is that the latest GDC version that works is<br>
> the gcc4.6 one (IIRC 2.057 based) - I have tried to migrate to a newer one<br>
> maybe 5 or 6 times over the last 1.5 year, and always run into some kind of<br>
> problem immediately after trying a new build.</p>
<p dir="ltr">What projects are you having problems with. My experience says that there are more frontend implementation problems than gdc glue when moving across several major versions. </p>
<p dir="ltr">> Like the last time, with the<br>
> failure of inlining of certain trivial functions. So when I then read about<br>
> a proposed new optimization, which sounds dubious to me, I ask about<br>
> more details, as I'm horrified that I could encounter yet another new GDC<br>
> specific problem during the next round of the let's-upgrade-gdc experience...<br>
></p>
<p dir="ltr">The failure of inlining is not a blocker IMO - relying on 'hidden' features, NRVO being another example, in user code is a bug. Regardless of the validity.  This particular problem has been noted and it is being dealt with by improving the relationship between differing variants of const and mutable types.</p>