[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
So if I look at what we generate for:

_Decimal64
truncd128 (_Decimal128 d)
{
  return d;
}

and:

_Decimal32
truncd64(_Decimal64 d)
{
  return d;
}

We basically just get a drdpq for the first function and a drsp for the second
function.  Ie, they don't change the rounding mode at all.  If I modify your
test case slightly to insert an intermediate cast to _Decimal64 like so:

_Decimal32
truncd128 (_Decimal128 d)
{
  return (_Decimal64)d;
}

...then we get:

        drdpq 12,2
        fmr 1,12
        drsp 1,1
        blr

So is changing the rounding mode really required here when we go from
_Decimal128 directly to _Decimal32?  If so, do the other casts also need to be
inserting rounding mode changes too?  If not, why not?

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
If you first round the DFP extended to DFP long and then to DFP short, it
can round in the same direction twice, giving the wrong result (say, for
round-to-nearest-even, you can end up with something more than 0.5ulp from
what you started with).

Doing everything but the final conversion down in round-to-odd mode works
correctly always.  It's magic :-)

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #2)
> Doing everything but the final conversion down in round-to-odd mode works
> correctly always.  It's magic :-)

Ok, so Paul's sequence is what we want and we don't need anything for the other
cases I mentioned since they're not double casting.  Thanks.

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
So the following pattern added to dfp.md:

+(define_insn "trunctdsd2"
+  [(set (match_operand:SD 0 "gpc_reg_operand" "=d")
+       (float_truncate:SD (match_operand:TD 1 "gpc_reg_operand" "d")))
+   (clobber (match_scratch:TD 2 "=d"))
+   (clobber (match_scratch:DF 3 "=&d"))]
+  "TARGET_DFP"
+  "mffs %3\;mtfsfi 7,7,1\;drdpq %2,%1\;mtfsf 0xff,%3,1,0\;drsp %0,%2"
+  [(set_attr "type" "dfp")
+   (set_attr "length" "20")])

Gives me the following on Paul's test case:

truncd128:
.LFB0:
        .cfi_startproc
        mffs 0
        mtfsfi 7,7,1
        drdpq 12,2
        mtfsf 0xff,0,1,0
        drsp 1,12
        blr

Does this look like what we want?

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
operands[2] needs an earlyclobber as well (it is written while some
operands are still read later).  Everything else is fine as far as I
can see :-)

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(So, pre-approved with that change, and with a testcase...  A run test
ideally, if that isn't too hard?)

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

--- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #5)
> operands[2] needs an earlyclobber as well (it is written while some
> operands are still read later).  Everything else is fine as far as I
> can see :-)

I originally had that early clobber as well, but the only operand still read
later is operands[3] which is already early clobber, so do we really need that?
 If we mark operands[2] early clobber, then we'll never be able to assign
operands[1] and operands[2] to the same hw register, which they could be.

If you still want operands[2] marked early clobber, I can do that.

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

--- Comment #8 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #7)
> If you still want operands[2] marked early clobber, I can do that.

Segher set me straight offline on why we need that early clobber too.
I'll kick off testing with that change.

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Peter Bergner <bergner@gcc.gnu.org>:

https://gcc.gnu.org/g:8a8c2573568aa17ada6163f90991701bc4470976

commit r11-2206-g8a8c2573568aa17ada6163f90991701bc4470976
Author: Peter Bergner <bergner@linux.ibm.com>
Date:   Fri Jul 17 21:06:30 2020 -0500

    rs6000: Generate _Decimal128 to _Decimal32 hardware conversion instructions

    We do not currently generate hardware conversion instructions when
    converting from _Decimal128 to _Decimal32.  There is no one instruction
    that does the conversion, so we currently call the __dpd_trunctdsd2
    lib function to do the conversion for us.  However, there is a short
    sequence of dfp hardware instructions that will do the conversion
    correctly.

    2020-07-17  Peter Bergner  <bergner@linux.ibm.com>

    gcc/
            PR target/92488
            * config/rs6000/dfp.md (trunctdsd2): New define_insn.
            * config/rs6000/rs6000.md (define_attr "isa"): Add p9.
            (define_attr "enabled"): Handle p9.

    gcc/testsuite/
            PR target/92488
            * gcc.target/powerpc/convert-fp-128.c (bl, drsp, drdpq): Update
counts.
            (__dpd_trunctdsd2): Make conditional on !hard_dfp.
            (__dpd_extendsddd2, __dpd_extendsdtd2, __dpd_truncddsd2,
            __dpd_extendddtd2, __dpd_trunctddd2): Use !hard_dfp.
            * gcc.target/powerpc/pr92488.c: New test.

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Peter Bergner <bergner at gcc dot gnu.org> ---
Fixed on trunk.

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Peter Bergner <bergner@gcc.gnu.org>:

https://gcc.gnu.org/g:699f9c0cc1bcc8acfd78c02315c963bf790c874d

commit r11-2258-g699f9c0cc1bcc8acfd78c02315c963bf790c874d
Author: Peter Bergner <bergner@linux.ibm.com>
Date:   Tue Jul 21 16:20:33 2020 -0500

    rs6000: Update test case count when compiling for power9

    2020-07-21  Peter Bergner  <bergner@linux.ibm.com>

    gcc/testsuite/
            PR target/92488
            * gcc.target/powerpc/convert-fp-128.c (bl): Update POWER9 count.