public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/102402] New: Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants
@ 2021-09-18 18:17 gabravier at gmail dot com
2021-09-18 18:35 ` [Bug tree-optimization/102402] " pinskia at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: gabravier at gmail dot com @ 2021-09-18 18:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102402
Bug ID: 102402
Summary: Seemingly suboptimal optimization of jmp/cmovcc for
conditionally loading constants
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include <stdint.h>
struct MusicPlayerTrack
{
uint8_t flags;
uint8_t modT;
};
void ClearModM(struct MusicPlayerTrack *track, uint8_t modT)
{
if (track->modT == 0)
track->flags |= 3;
else
track->flags |= 12;
}
This is optimized weirdly by GCC. Leaving it as-is gives this AMD64 assembly:
ClearModM:
movzx edx, BYTE PTR [rdi]
mov eax, edx
or eax, 12
cmp BYTE PTR [rdi+1], 0
jne .L3
mov eax, edx
or eax, 3
.L3:
mov BYTE PTR [rdi], al
ret
Whereas changing the `if` to `if (modT == 0)` gives this:
ClearModM:
movzx eax, BYTE PTR [rdi]
mov edx, eax
or eax, 12
or edx, 3
test sil, sil
cmove eax, edx
mov BYTE PTR [rdi], al
ret
It seems to me that this should be better than the first output, though of
course this could be the other way considering how finicky cmovcc seems to be,
but it seems to me like at least one should be preferred above the other.
Note that this also occurs on IA-32, so the issue seems unrelated to whether
modT is in a register or in memory. Perhaps it's about whether it's a function
argument ?
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug tree-optimization/102402] Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants
2021-09-18 18:17 [Bug target/102402] New: Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants gabravier at gmail dot com
@ 2021-09-18 18:35 ` pinskia at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-18 18:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102402
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Component|target |tree-optimization
Last reconfirmed| |2021-09-18
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed, note the best code is generated by:
void ClearModM1(struct MusicPlayerTrack *track, uint8_t modT)
{
int t =0;
if (track->modT == 0)
t = 3;
else
t = 12;
track->flags |= t;
}
This is then a gimple level issue where:
if (_1 == 0)
goto <bb 3>; [50.00%]
else
goto <bb 4>; [50.00%]
<bb 3> [local count: 536870913]:
_3 = pretmp_6 | 3;
goto <bb 5>; [100.00%]
<bb 4> [local count: 536870913]:
_5 = pretmp_6 | 12;
<bb 5> [local count: 1073741824]:
# cstore_12 = PHI <_3(3), _5(4)>
is not transformed into:
if (track->modT == 0)
t = 3;
else
t = 12;
cstore_12 = pretmp_6 | t;
There is also a sinking issue though I don't know if has a wider effect (and
does not matter in this case really).
Take:
void ClearModM1(struct MusicPlayerTrack *track, uint8_t modT)
{
int t =0;
int t2 = track->modT;
int t1 = track->flags;
if (t2 == 0)
t = 3;
else
t = 12;
track->flags = t1|t;
}
The load for track->flags is not sunk after the if.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-09-18 18:35 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-18 18:17 [Bug target/102402] New: Seemingly suboptimal optimization of jmp/cmovcc for conditionally loading constants gabravier at gmail dot com
2021-09-18 18:35 ` [Bug tree-optimization/102402] " pinskia 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).