Missed optimisation case - internal use of STCin

Sun Apr 20 13:11:05 PDT 2014

On 20 April 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.
> 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).
> 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. This was a few years ago, after you'd fixed
> the many small problems I had run into. The type of those issues made it
> very clear that I was the only one that was trying to really use GDC.
> Unfortunately what happened then was that things started to get worse, and
> by worse I mean "unusable"; GDC ceased to be able to deliver functionality
> and performance that was in the same league as GCC C/C++. LTO stopped
> working (which is not only crucial for a language w/o macros and low-level
> control, but was useful as a work-around for tool issues, like the lack
> of cross module inlining).

I have not seen this, infact the opposite.

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.

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).

> The accepted language changed in a way that
> was completely backward incompatible and would have required an extra
> preprocessing step (pragma-attributes were removed and became hard
> errors). GCC attributes became inaccessible; things like @pure, @malloc,
> @ifunc, @align, @cold, @regparm all used to work, but now didn't. @inline,
> @noinline and @flatten were added back as /true/ D-style attributes later,
> and seem to work great.

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.

> Thanks for exposing those, but my concern is that
> dealing with them one-by-one does not scale - that's why I haven't filed
> any bug reports wrt the other ones.

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.

> Your work on getting D support merged
> into GCC is critically important for the survival of the language; things
> that are merely optimizations can happen later, or will be mostly
irrelevant
> (if the merge never happens).
> But the situation right now is that the latest GDC version that works is
> the gcc4.6 one (IIRC 2.057 based) - I have tried to migrate to a newer one
> maybe 5 or 6 times over the last 1.5 year, and always run into some kind
of
> problem immediately after trying a new build.

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.

> Like the last time, with the
> failure of inlining of certain trivial functions. So when I then read
about
> a proposed new optimization, which sounds dubious to me, I ask about
> more details, as I'm horrified that I could encounter yet another new GDC
> specific problem during the next round of the let's-upgrade-gdc
experience...
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140420/1d958af5/attachment.html>