https://issues.dlang.org/show_bug.cgi?id=23472

kinke <kinke@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #1 from kinke <kinke@gmx.net> ---
The frontend lowers this to:

```
char inc(string s, ref int i)
{
        bool __os2 = false;
        try
        {
                try
                {
                        return s[cast(ulong)i];
                }
                catch(Throwable __o3)
                {
                        __os2 = true;
                        throw __o3;
                }
        }
        finally
                if (!__os2)
                        i++;
}
```

So the increment is to be skipped if the bounds check fails. Using -release etc. allows the LLVM optimizer to get rid of all EH boilerplate.

--

https://issues.dlang.org/show_bug.cgi?id=23472

--- Comment #2 from deadalnix <deadalnix@gmail.com> ---
`__os2` can only be false if no exception was thrown. There is no reason to emit any exception handling code in such function, even in the instances where the bound check might fail.

In fact, the whole point of scope success is "run this when the scope is exited using regular control flow rather than exception handling", so there is no reason to emit any exception handling code ever when dealing with scope(success).

--

https://issues.dlang.org/show_bug.cgi?id=23472

--- Comment #3 from kinke <kinke@gmx.net> ---
> so there is no reason to emit any exception handling code ever when
> dealing with scope(success).

That only holds for trivial code like your example. With multiple return statements like

char inc(string s, ref int i) {
    scope(success) i++;
    if (s == null)
        return 0;
    if (s.length > 256)
        return 1;
    return s[i];
}

the general frontend lowering does make sense, IMO at least. ;)

--

https://issues.dlang.org/show_bug.cgi?id=23472

--- Comment #4 from deadalnix <deadalnix@gmail.com> ---
No, that is true in general. For instance, you exemple:

char inc(string s, ref int i) {
    scope(success) i++;
    if (s == null)
        return 0;
    if (s.length > 256)
        return 1;
    return s[i];
}

Is trivially equivalent to:

char inc(string s, ref int i) {
    char ret;
    if (s == null) {
        ret = 0;
        goto Exit;
    }
    if (s.length > 256) {
        ret = 1:
        goto Exit;
    }

    ret = s[i];

Exit:
    i++;
    return ret;
}

--

https://issues.dlang.org/show_bug.cgi?id=23472

--- Comment #5 from kinke <kinke@gmx.net> ---
Almost - this basically corresponds to what the backend generates for the happy path without exception, except that the assignments to `ret` need to be constructions (`TOK.construct`) in order not to break in-place construction of the return value for non-POD return types.

Such an invasive rewrite should be feasible in the frontend, but would presumably be quite a bit of work, for little gain IMO.

--

https://issues.dlang.org/show_bug.cgi?id=23472

--- Comment #6 from deadalnix <deadalnix@gmail.com> ---
You see what I mean. The backend is not bound by this, it can hold onto the value as an rvalue and return it.

An alternative here is to remove empty exception handling code, such as empty finally blocks, or catch blocks that immediately rethrow. In fact, this is probably something we want standalone in LDC's optimizer pipeline, as I'd expect it could find numerous wins.

--

https://issues.dlang.org/show_bug.cgi?id=23472

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

https://issues.dlang.org/show_bug.cgi?id=23472

--- Comment #7 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/20182

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--