[Bug target/116014] Missed optimization opportunity: inverted shift count

[bisqwit at iki dot fi via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116014

--- Comment #2 from Joel Yliluoma <bisqwit at iki dot fi> ---
(In reply to Andi Kleen from comment #1)
> is that from some real code? why would a programmer write shifts like that?

Yes, it is from actual code:

    uint64_t readvlq()
    {
        uint64_t x, f = ~(uint64_t)0, ones8 = f / 255, pat80 = ones8*0x80,
pat7F=ones8*0x7F;
        memcpy(&x, ptr, sizeof(x));
        uint8_t n = __builtin_ctzll(~(x|pat7F)) + 1;
        ptr += n/8;
        return _pext_u64(x, pat7F >> (64-n));
    }

This function reads a variable-length encoded integer (as in General MIDI) from
a bytestream without loops or branches. It essentially does the same as this:

    uint64_t readvlq()
    {
        uint64_t result = 0;
        do { result = (result << 7) | (*ptr & 0x7F); } while(*ptr++ & 0x80);
        return result;
    }

It isn’t too hard to think of plausible other cases where bitshifts with
numberofbits(tgt)-variable may occur. In fact, after just 2 minutes of
searching with `grep`, I found this line in LLVM
(llvm-17/llvm/Bitstream/BitstreamWriter.h), where CurValue is a 32-bit entity:

    CurValue = Val >> (32-CurBit);