[Bug target/100391] New: 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts

["zero at smallinteger dot com" <gcc-bugzilla@gcc.gnu.org>]

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.