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

Nick Sabalausky <cbkbbejeap@mailinator.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbkbbejeap@mailinator.com

--- Comment #3 from Nick Sabalausky <cbkbbejeap@mailinator.com> ---
(In reply to Trass3r from comment #2)
> I tried back then but didn't succeed.
> IIRC we need a way to quickly and reliably detect the infinite loop from a
> script.

Maybe a modified version of this?:

https://github.com/CyberShadow/DustMite/wiki/Running-commands-with-a-timeout

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #4 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Some notes for Walter.

The bottleneck is the `static this()` in gtk.d starting line 36.

This function itself is over 3800 lines long.

Notable problematic functions.

1. dmd/backend/gflow.d: initDNunambigVectors()

This function is a massive bottleneck, as you're effectively doing:
---
// In initDNunambigVectors()
foreach (uint i; 0 .. go.deftop)
{
   // In fillInDNunambig()
   foreach (uint i; 0 .. go.deftop)
   {
      // ...
   }
}
---

In the unreduced test, go.deftop = 25144.  You are also calling this function twice in dmd/backend/go.d:optfunc.  The main entrypoint being constprop().


2. dmd/backend/gother.d: accumda()

Suffers from a similar problem.  It is recursively called 25144 times in the OTbinary path.


3. dmd/backend/gflow.d: accumaecpx():

Likewise, it is recursively called

- 56572 times in the first iteration (before accumda).
- 28286 times in a second iteration (after accumda).


4. dmd/backend/gdag.d: aewalk():

Likewise, it is recursively called 50287 times.

--

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

--- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> ---
I can't reproduce an infinite loop, but...

$ time ../../generated/linux/release/64/dmd -v -release -O -inline -m64 -Isrc
-c src/gtkc/gtk.d
real    1m38.327s
user    1m37.710s
sys     0m0.512s


Getting close to two minutes compilation time.

--

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

--- Comment #6 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Somewhat reduced test:
---
enum LIBRARY
{
    GTK
}

struct Linker
{
    static void link(T)(ref T funct, string symbol, LIBRARY[] libraries ...)
    {
    }
}

static this()
{
    static foreach(i; 0 .. 10_000)
        Linker.link(somefunc, "somefunc", LIBRARY.GTK);
}

void function() c_somefunc;
alias c_somefunc  somefunc;
---

To prove that this isn't too much of a contrived test, I checked the compile times of other compilers.

dmd -O -release -inline | 3 minutes 12 seconds.
gdc -O2 -frelease       | 6 seconds.
ldc -O2 -release        | 8 seconds.


Actually, the dmd compiler segfaults, I assume because I managed to hit a stack overflow.

--

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

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com

--- Comment #7 from Basile-z <b2.temp@gmx.com> ---
the game changer is more the -O switch than -inline.
The test case with -release -inline gets successfully compiled, even if it's
slow (50 secs here).

--

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

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|b2.temp@gmx.com             |

--

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

safety0ff.bugz <safety0ff.bugz@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=19550

--

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

safety0ff.bugz <safety0ff.bugz@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|https://issues.dlang.org/sh |
                   |ow_bug.cgi?id=19550         |

--

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

safety0ff.bugz <safety0ff.bugz@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |safety0ff.bugz@gmail.com

--- Comment #8 from safety0ff.bugz <safety0ff.bugz@gmail.com> ---
Once the patch for bug 19550 is applied, this bug should be a duplicate of bug #7157.

The common issue with #7157 is that `aewalk` use an O(N) search for available expressions to reduce expressions. This subsequently leads to a blow of `el_match` calls.

It should be possible to fix this by changing the O(N) search to a sorted
search or hashing scheme.

--

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

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |21121


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=21121
[Issue 21121] Optimizer slowdowns
--