www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5455] New: Optimization (register allocation?) regression in DMD 1.065

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455

           Summary: Optimization (register allocation?) regression in DMD
                    1.065
           Product: D
           Version: D1
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: thecybershadow gmail.com
                CC: thecybershadow gmail.com


--- Comment #0 from Vladimir <thecybershadow gmail.com> 2011-01-14 18:51:29 PST
---
Created an attachment (id=871)
Partially minimized test case

I've stumbled upon a rather weird regression, which was introduced in DMD
1.065: when compiling specific code with -O -release -inline, it ICEs with
"Internal error: ..\ztc\cgcod.c 1649".

The test case seems to be quite resistant to "minimization", and even moving
functions from one module to another seems to make the bug vanish. I've reduced
the test case to four modules, and somewhat minimized the first two, but I'm
willing to give up for now at this point. If any compiler developer decides
that minimizing the test case is worth it, I'll give it another shot as soon as
I get over my cold.

As I went to post this, I noticed that I was still using DMD 1.065. However,
DMD 1.066 outright crashes.

To reproduce, compile the attached files with:

dmd -O -release -inline Common.d Data.d Gzip.d Zlib.d

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 14 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au
            Version|D1                          |D1 & D2


--- Comment #1 from Don <clugdbug yahoo.com.au> 2011-01-17 00:22:27 PST ---
This doesn't fail in the D1 version in svn.
This doesn't ICE on svn 852 "reduce reliance on varargs" but did ICE on svn 851
and earlier.
Here's a slightly reduced test case which ICEs on the version of D2 in svn.
Still requires -O -inline -release.
----
final class DataWrapper
{
    void* dat;

    void[] contents()
    {
        return dat[0..1];
    }
}

class Data
{
private:
    DataWrapper wrapper;
    size_t start, end;

public:
    this(void[] data) {}
    size_t length()
    {
        return end - start;
    }
}

Data daz(Data srcbuf)
{
    throw new Exception("xxx");
}

uint crc32(void[] data)
{
    int w;
    foreach(v;cast(ubyte[])data)
    {
        ++w;
    }
    return 0;
}


class HttpResponse
{
    Data zug;

    void setContent(Data data, string[] supported)
    {
        foreach(method;supported)
            switch(method)
            {
                default:
                    uint[] footer = [crc32(data.wrapper ?
data.wrapper.contents[data.start..data.end] : null ), data.end - data.start];
                    zug = daz(data);
                    return;
            }
    }
}
----

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 17 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Optimization (register      |ICE(cgcod.c): Optimization
                   |allocation?) regression in  |(register allocation?)
                   |DMD 1.065                   |regression in DMD 1.065
           Severity|normal                      |regression


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 17 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455



--- Comment #2 from Don <clugdbug yahoo.com.au> 2011-01-17 11:44:32 PST ---
This is amazing. I have never before seen such an irreducible test case.
Here's the best I've been able to do.
-----
void thrw(Data *s) {
    throw new Exception("xxx");
}

struct Data {
    Rapper *w;
    uint n, m;
}

struct Rapper {
    ubyte * dat;
    ubyte[] con() {
        return dat[0..1];
    }
}

uint jaz(ubyte[] data) {
    return data.length;
}

struct Resp {
    void set(Data *data, string[] soup) {
        switch(soup[0]) {
            default:
        }
        uint[] f = [jaz(data.w ? data.w.con[data.n ..data.m] : null), data.m -
data.n];
        thrw(data);
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 17 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455



--- Comment #3 from Don <clugdbug yahoo.com.au> 2011-01-18 12:44:11 PST ---
I think there's something wrong in cgcod.c, allocreg(). Might be good to have
an assert on line 1920:


                r &= mLSW;                      /* see if there's an LSW also
*/
                if (r)
                    lsreg = findreg(r);
                else if (lsreg == -1)   /* if don't have LSW yet */
                {       retregs &= mLSW;
+                   assert(retregs);
                    goto L3;
                }
            }

This fails. What happens is, we've found a register for the MSW. But we got
called with no available LSW registers!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455



--- Comment #4 from Don <clugdbug yahoo.com.au> 2011-01-24 14:03:21 PST ---
The regression was introduced in git revision
0eb915bf22045b3c34f23e63859bf8361b2d5a7a, 2010-10-24
with the helpful commit comment "more 64 bit stuff".

That commit was TYint-> TYsizet changes, so it shouldn't have had any effect at
all on the generated code for 32 bits.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455



--- Comment #5 from Don <clugdbug yahoo.com.au> 2011-01-25 00:27:34 PST ---
The bug was triggered by this change to SliceExp::toElem() (now line 4426):

---
        elem *eptr = array_toPtr(e1->type, e);
-        elem *elength = el_bin(OPmin, TYint, eupr, elwr2);
+        elem *elength = el_bin(OPmin, TYsize_t, eupr, elwr2);
        eptr = el_bin(OPadd, TYnptr, eptr, el_bin(OPmul, TYsize_t,
el_copytree(elwr2), el_long(TYsize_t, sz)));

        e = el_pair(TYdarray, elength, eptr);
        e = el_combine(elwr, e);
        e = el_combine(einit, e);
---
Reverting this change removes the ICE.
TYsize_t is a TYuint, rather than a TYint.
Still, I don't understand why it makes any difference.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455



--- Comment #6 from Don <clugdbug yahoo.com.au> 2011-01-25 13:07:25 PST ---
I think what's happened, is that a minor change to support 64 bits has
triggered a latent bug in the backend.

Basically, cgreg_assign() in cgreg.c thinks there are enough free registers. 
But allocreg() in cgcod.c can't find one. Although it is called with two
available registers, one of them is EBP, and EBP is disallowed in line 1910.
So these two functions are inconsistent.

I think the problem may be in creg_assign(). It thinks it has freed up a
register (EBX) which is used for 'this'. But (if I've correctly understood what
the code is doing) the same register seems to be used in a double-reg combo.
Seems a bit similar to bug 4443.
If I'm correct, then a solution to this bug would be to check if the register
is also part of a double-reg variable, before marking it as freed-up.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 25 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5455


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED


--- Comment #7 from Walter Bright <bugzilla digitalmars.com> 2011-02-11
22:59:37 PST ---
https://github.com/D-Programming-Language/dmd/commit/55da7194b3f626d1183fcd5404597749e4e21e15

https://github.com/D-Programming-Language/dmd/commit/bf6d6884d68783fb4007bfe6fa9f125a77538ef2

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 11 2011