public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/111597] New: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64
@ 2023-09-26 7:43 guojiufu at gcc dot gnu.org
2023-09-26 8:04 ` [Bug target/111597] " guojiufu at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: guojiufu at gcc dot gnu.org @ 2023-09-26 7:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
Bug ID: 111597
Summary: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal
for ppc64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
In match.pd there is a pattern:
/* ((T)(A)) + CST -> (T)(A + CST) */
#if GIMPLE
(simplify
(plus (convert:s SSA_NAME@0) INTEGER_CST@1)
(if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
&& TREE_CODE (type) == INTEGER_TYPE
&& TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
&& int_fits_type_p (@1, TREE_TYPE (@0)))
/* Perform binary operation inside the cast if the constant fits
and (A + CST)'s range does not overflow. *
But this pattern seems not in favor of all targets.
For example, the below code hits this pattern,
long foo1 (int x)
{
if (x>1000)
return 0;
int x1 = x +1;
return (long) x1 + 40;
}
Compile with "-O2 -S", on ppc64le, the generated asm is:
cmpwi 0,3,1000
bgt 0,.L3
addi 3,3,41
extsw 3,3 ;; this is suboptimal
blr
.p2align 4,,15
.L3:
li 3,0
blr
--------------
But for the below code, the generated asm seems better: without
long foo1 (int x)
{
if (x>1000)
return 0;
return (long) x + 40;
}
cmpwi 0,3,1000
bgt 0,.L3
addi 3,3,40
blr
.p2align 4,,15
.L3:
li 3,0
blr
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64
2023-09-26 7:43 [Bug target/111597] New: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64 guojiufu at gcc dot gnu.org
@ 2023-09-26 8:04 ` guojiufu at gcc dot gnu.org
2023-09-26 8:08 ` rguenth at gcc dot gnu.org
2023-09-26 8:35 ` guojiufu at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: guojiufu at gcc dot gnu.org @ 2023-09-26 8:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
--- Comment #1 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
While, even without this pattern in match.pd, the generated the sign
extend(extsw) is still there.
So, just wondering if this sub-optimal asm code would be fixed in another way.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64
2023-09-26 7:43 [Bug target/111597] New: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64 guojiufu at gcc dot gnu.org
2023-09-26 8:04 ` [Bug target/111597] " guojiufu at gcc dot gnu.org
@ 2023-09-26 8:08 ` rguenth at gcc dot gnu.org
2023-09-26 8:35 ` guojiufu at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-09-26 8:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
CC| |rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So it's only because the incoming x is sign-extended to long due to the ABI?
Seems to be a quite "localized" issue. Btw, it was ppc folks requesting this
pattern as a building block for a larger transform.
It's always difficult to use canonicalizations to do simplifications.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug target/111597] pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64
2023-09-26 7:43 [Bug target/111597] New: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64 guojiufu at gcc dot gnu.org
2023-09-26 8:04 ` [Bug target/111597] " guojiufu at gcc dot gnu.org
2023-09-26 8:08 ` rguenth at gcc dot gnu.org
@ 2023-09-26 8:35 ` guojiufu at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: guojiufu at gcc dot gnu.org @ 2023-09-26 8:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111597
--- Comment #3 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
(In reply to Jiu Fu Guo from comment #0)
> In match.pd there is a pattern:
> /* ((T)(A)) + CST -> (T)(A + CST) */
> #if GIMPLE
> (simplify
> (plus (convert:s SSA_NAME@0) INTEGER_CST@1)
> (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
> && TREE_CODE (type) == INTEGER_TYPE
> && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
> && int_fits_type_p (@1, TREE_TYPE (@0)))
> /* Perform binary operation inside the cast if the constant fits
> and (A + CST)'s range does not overflow. *
>
> But this pattern seems not in favor of all targets.
> For example, the below code hits this pattern,
>
> long foo1 (int x)
> {
> if (x>1000)
> return 0;
> int x1 = x +1;
> return (long) x1 + 40;
>
> }
For this code, without the pattern "((T)(A)) + CST -> (T)(A + CST)",
the final gimple code is:
x1_4 = x_3(D) + 1;
_1 = (long int) x1_4;
_5 = _1 + 40;
With the pattern,
the final gimple code is:
_4 = x_2(D) + 41;
_3 = (long int) _4;
So, this pattern would be "reasonable".
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-09-26 8:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-26 7:43 [Bug target/111597] New: pattern "(T)(A)+cst -->(T)(A+cst)" cause suboptimal for ppc64 guojiufu at gcc dot gnu.org
2023-09-26 8:04 ` [Bug target/111597] " guojiufu at gcc dot gnu.org
2023-09-26 8:08 ` rguenth at gcc dot gnu.org
2023-09-26 8:35 ` guojiufu 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).