public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/100391] New: 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts
@ 2021-05-03 8:43 zero at smallinteger dot com
2021-05-03 18:49 ` [Bug tree-optimization/100391] " pinskia at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: zero at smallinteger dot com @ 2021-05-03 8:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100391
Bug ID: 100391
Summary: 128 bit arithmetic --- many unnecessary instructions
when extracting smaller parts
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zero at smallinteger dot com
Target Milestone: ---
Created attachment 50738
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50738&action=edit
Sample code
Consider the attached code, compiled with -O2. The return value of both
functions is just the low 32 bits of num. Whether the top 4 bits of kt were
zero, or became zero because of the shifts in the if statement, is irrelevant.
So, this both functions should have resulted in something like
twostep(unsigned __int128): # @twostep(unsigned
__int128)
mov rax, rdi
ret
onestep(unsigned __int128): # @onestep(unsigned
__int128)
mov rax, rdi
ret
Instead, gcc added many unnecessary instructions to twostep() as shown below.
twostep(unsigned __int128):
mov rcx, rdi
mov rax, rdi
shr rcx, 60
je .L2
movabs rdx, 1152921504606846975
and rax, rdx
.L2:
ret
onestep(unsigned __int128):
mov rax, rdi
ret
This particular behavior was isolated while examining the output of gcc 9.3.0
on Ubuntu 20.04 LTS, then verified for the stated versions (and a few others)
using Godbolt.
Incidentally, it might be worth checking whether movabs + and is indeed faster
than shl + shr, assuming doing so was necessary. If too many movabs
instructions are generated for bit masking like this, it will run against the
Intel optimization manual's recommendation not to include too many full size
literals in code.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug tree-optimization/100391] 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts
2021-05-03 8:43 [Bug target/100391] New: 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts zero at smallinteger dot com
@ 2021-05-03 18:49 ` pinskia at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-05-03 18:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100391
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Component|target |tree-optimization
Last reconfirmed| |2021-05-03
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. There is a missed optimization at the tree level in the first
place.
The cast to uint32_t is not prograded back through the PHI node.
_1 = kt_4 >> 60;
if (_1 != 0)
goto <bb 3>; [50.00%]
else
goto <bb 4>; [50.00%]
<bb 3> [local count: 536870913]:
kt_5 = kt_4 & 1152921504606846975;
<bb 4> [local count: 1073741824]:
# kt_2 = PHI <kt_4(2), kt_5(3)>
_6 = (uint32_t) kt_2;
If it was then the above would have became just:
_6 = (uint32_t) kt_4;
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-05-03 18:49 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-03 8:43 [Bug target/100391] New: 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts zero at smallinteger dot com
2021-05-03 18:49 ` [Bug tree-optimization/100391] " 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).