Missed optimisation case - internal use of STCin

[Artur Skawina via Digitalmars-d]

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


>>> - Defining reliable strict aliasing rules, it turns out, is not that
>>> simple (this is something that Walter has mentioned about D should
>>> have good guarantees for, ie: D arrays).
>>
>> Short term, disabling strict aliasing is the only option. I was scared
>> of the impact it had before you even started to add support for it a
>> few years ago (the codegen was already different w/ -fno-strict-aliasing
>> before, which meant that I immediately had to disable it everywhere...)
>> There probably does not exist a single D program that respects strict
>> aliasing rules, other than by chance. The perf gains are minimal globally,
>> but the potential for silent data corruption is huge.
> 
> I think the performance gains are worthy of note, most benchmarks tend
> to suggest that code is at least 5% slower with strict aliasing
> optimisations turned off.

I'd like to avoid something like the GCC C strict-aliasing disaster.
String-aliasing helps some code, but breaks some other (legacy) code.
Turning on strict-aliasing by default and recompiling the whole userspace
(hundreds of packages, thousands of sources) is not going to make any
noticeable difference for a desktop user, yet it is likely to trigger
data-corrupting bugs /somewhere/. So the result is practically no perf
gain, but a non-zero chance of corrupting user data, often by programs
that are not perf sensitive at all - that's not a good trade-off.
D doesn't have the MLOCs of legacy code, but I doubt that the D code
that exists was written with strict aliasing in mind. Especially since
the rules are not exactly well defined.

artur