#2540 long long issues on mcs51

[Philipp Klaus Krause]

The following regression tests fail for mcs51 when enabled:

pr42269-2.c
20000314-2.c
20000412-2.c
20000717-2.c

It seems the problem are mcs51-specific long long issues.

Philipp

[Philipp Klaus Krause]

I looked at the genrated asm a bit. It seems peephole 301 sometimes optimized out the writes of the upper 32 bit of long long return values. See e.g. tests/gcc-torture-execute-pr42269-2.c resulting in the following asm:

–
    mov r2,a
    mov r3,a
;   Peephole 301    mov r4,a removed
;   Peephole 301    mov r5,a removed
;   Peephole 301    mov r6,a removed
;   Peephole 301    mov r7,a removed
;   genRet
    mov dpl,r0
    mov dph,r1
    mov b,r2
    mov a,r3
;   Peephole 500    removed redundant label 00101$
    ret

It seesm like deadMove(%1) doesn't work for functions returning long long. I guess someone more familiar with the mcs51 peephole infrastructure should have a look.

Philipp

[Philipp Klaus Krause]

20000412-2.c in an issue unrelated to long long.
But the other three are all the same problem with peephole 301.

Philipp

[Maarten Brock]

Here's one untested portion for scan4op() in mcs51/peep.c. Also include gen.h and enable the export of fReturn8051 in it.

This should leave the movs in place before a ret.

                /* it's a normal function return */
                if (!((*pl)->ic))
                  return S4O_ABORT; /* but no ic? */
                if (!IS_SYMOP (IC_LEFT ((*pl)->ic)))
                  return S4O_TERM;  /* no function name? */
                ftype = OP_SYM_TYPE (IC_LEFT ((*pl)->ic));
                if (!IS_FUNC (ftype))
                  return S4O_TERM;  /* not a function? */
                if (FUNC_CALLEESAVES (ftype))
                  return S4O_ABORT; /* returning from callee saves function */
                if (getSize(OP_SYM_ETYPE(IC_LEFT((*pl)->ic))) > 4)
                  {
                    for (unsigned i = 0; i < fReturnSizeMCS51; i++)
                      if (strcmp (fReturn8051[i], pReg) == 0)
                        return S4O_ABORT; /* return value is partially in r4-r7 */
                  }
                return S4O_TERM;

[Philipp Klaus Krause]

I did a bit of testing and modified it to this:

                /* it's a normal function return */
                if (!((*pl)->ic))
                  return S4O_ABORT; /* but no ic? */
                if (!currFunc->type)
                  return S4O_ABORT;  /* not a function? */
                if (FUNC_CALLEESAVES (currFunc->type))
                  return S4O_ABORT; /* returning from callee saves function */
                if (getSize(currFunc->etype) > 4)
                  {
                    for (unsigned i = 0; i < getSize(currFunc->etype); i++)
                      if (strstr (pReg, fReturn8051[i]))
                        return S4O_ABORT; /* return value is partially in r4-r7 */
                  }
                return S4O_TERM;

This fixes pr42269-2.c and 20000314-2.c, but there is still an issue in 20000717-2.c.

Philipp

[Philipp Klaus Krause]

Comitted in rev. [r9739]. However, I had to disable gcc-torture-execute-20060110-2.c, which is affected by a bug that was masked by this one.

Philipp

[Philipp Klaus Krause]

The remaining issue in 20000717-2.c is due to peephole 301 partially optimizing out the long long parameter. Might need a fix in termScanAtFunc().

Philipp

[Maarten Brock]

The above patch only fixes return values. It does not prevent destruction of parameters. That should be fixed in termScanAtFunc() in mcs51/peep.c similar to how r0-r2 are preserved for banked function calls.

[Ben Shi]

I have found more issues on cygwin64,

gcc-torture-execute-20000717-2.c fails for mcs51-xstack-auto, mcs51-large, mcs51-medium, mcs51-huge.
gcc-torture-execute-961122-1.c fails for mcs51-small.
/gcc-torture-execute-20060110-2.c fails for mcs51-stack-auto, mcs51-large-stack-auto.

[Ben Shi]

There are other cases fail for mcs51 longlong.

[Philipp Klaus Krause]

Before 3.7.0, most mcs51 long long issues got fixed. Of the issues discussed here, there is only one aspect remaining:

gcc-torture-execute-20060110-2 fails for mcs51-medium.

Philipp

[Philipp Klaus Krause]

As of [r10315] that test passes, probably due to recent mcs51 fixes.