public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/114567] New: rs6000: explicit _Float128 doesn't generate optimal code
@ 2024-04-03 2:05 linkw at gcc dot gnu.org
2024-04-03 2:06 ` [Bug target/114567] " linkw at gcc dot gnu.org
2024-04-10 8:42 ` linkw at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: linkw at gcc dot gnu.org @ 2024-04-03 2:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
Bug ID: 114567
Summary: rs6000: explicit _Float128 doesn't generate optimal
code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
This is an issue which I happened to spot when I have been working on patches
for PR112993.
=== test case ===
#define TYPE _Float128
#ifdef LD
#undef TYPE
#define TYPE long double
#endif
int sbm (TYPE *a) { return __builtin_signbit (*a); }
==================
/opt/gcc-nightly/trunk/bin/gcc -mcpu=power8 -mvsx -O2 -mabi=ieeelongdouble
-Wno-psabi test.c -DLD -S -o ref.s
/opt/gcc-nightly/trunk/bin/gcc -mcpu=power8 -mvsx -O2 -mabi=ibmlongdouble
-Wno-psabi test.c -S -o float128.s
diff -Nur ref.s float128.s
--- ref.s 2024-03-18 05:41:00.302208975 -0400
+++ float128.s 2024-03-18 05:41:00.392205513 -0400
@@ -9,7 +9,10 @@
sbm:
.LFB0:
.cfi_startproc
- ld 3,8(3)
+ rldicr 3,3,0,59
+ lxvd2x 0,0,3
+ xxpermdi 0,0,0,2
+ mfvsrd 3,0
srdi 3,3,63
blr
.long 0
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug target/114567] rs6000: explicit _Float128 doesn't generate optimal code
2024-04-03 2:05 [Bug target/114567] New: rs6000: explicit _Float128 doesn't generate optimal code linkw at gcc dot gnu.org
@ 2024-04-03 2:06 ` linkw at gcc dot gnu.org
2024-04-10 8:42 ` linkw at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: linkw at gcc dot gnu.org @ 2024-04-03 2:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |15.0
Keywords| |missed-optimization
Target| |powerpc64*-linux-gnu
Last reconfirmed| |2024-04-03
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug target/114567] rs6000: explicit _Float128 doesn't generate optimal code
2024-04-03 2:05 [Bug target/114567] New: rs6000: explicit _Float128 doesn't generate optimal code linkw at gcc dot gnu.org
2024-04-03 2:06 ` [Bug target/114567] " linkw at gcc dot gnu.org
@ 2024-04-10 8:42 ` linkw at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: linkw at gcc dot gnu.org @ 2024-04-10 8:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
This is power8 LE specific, for KFmode its mov expander calls
rs6000_emit_le_vsx_move, so it's with V1TI subreg, then rs6000 specific pass
swaps generate one MEM with AND -16, which make combine unable to optimize it
with that *signbit<mode>2_dm_mem pattern due to mode_dependent_address_p
returning false always for AND. Although it looks to me we can extend
mode_dependent_address_p to consider the to-mode in that context, it's still
sub-optimal due to the existence of AND -16, which result in an explicit "and"
then.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-04-10 8:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-03 2:05 [Bug target/114567] New: rs6000: explicit _Float128 doesn't generate optimal code linkw at gcc dot gnu.org
2024-04-03 2:06 ` [Bug target/114567] " linkw at gcc dot gnu.org
2024-04-10 8:42 ` linkw at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).