* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
@ 2020-07-13 16:14 ` bergner at gcc dot gnu.org
2020-07-15 0:04 ` segher at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-07-13 16:14 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
2020-07-13 16:14 ` [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp bergner at gcc dot gnu.org
@ 2020-07-15 0:04 ` segher at gcc dot gnu.org
2020-07-15 2:51 ` bergner at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2020-07-15 0:04 UTC (permalink / raw)
To: gcc-bugs
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 :-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
2020-07-13 16:14 ` [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp bergner at gcc dot gnu.org
2020-07-15 0:04 ` segher at gcc dot gnu.org
@ 2020-07-15 2:51 ` bergner at gcc dot gnu.org
2020-07-15 20:33 ` bergner at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-07-15 2:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-07-15 2:51 ` bergner at gcc dot gnu.org
@ 2020-07-15 20:33 ` bergner at gcc dot gnu.org
2020-07-15 21:04 ` segher at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-07-15 20:33 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-07-15 20:33 ` bergner at gcc dot gnu.org
@ 2020-07-15 21:04 ` segher at gcc dot gnu.org
2020-07-15 21:05 ` segher at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2020-07-15 21:04 UTC (permalink / raw)
To: gcc-bugs
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 :-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-07-15 21:04 ` segher at gcc dot gnu.org
@ 2020-07-15 21:05 ` segher at gcc dot gnu.org
2020-07-15 21:13 ` bergner at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2020-07-15 21:05 UTC (permalink / raw)
To: gcc-bugs
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?)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-07-15 21:05 ` segher at gcc dot gnu.org
@ 2020-07-15 21:13 ` bergner at gcc dot gnu.org
2020-07-15 21:31 ` bergner at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-07-15 21:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-07-15 21:13 ` bergner at gcc dot gnu.org
@ 2020-07-15 21:31 ` bergner at gcc dot gnu.org
2020-07-18 2:12 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-07-15 21:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-07-15 21:31 ` bergner at gcc dot gnu.org
@ 2020-07-18 2:12 ` cvs-commit at gcc dot gnu.org
2020-07-18 2:14 ` bergner at gcc dot gnu.org
2020-07-21 21:23 ` cvs-commit at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-07-18 2:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-07-18 2:12 ` cvs-commit at gcc dot gnu.org
@ 2020-07-18 2:14 ` bergner at gcc dot gnu.org
2020-07-21 21:23 ` cvs-commit at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2020-07-18 2:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
[not found] <bug-92488-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2020-07-18 2:14 ` bergner at gcc dot gnu.org
@ 2020-07-21 21:23 ` cvs-commit at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-07-21 21:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread