[Bug tree-optimization/109931] New: Knowledge on literal not used in optimization

[Bug tree-optimization/109931] New: Knowledge on literal not used in optimization

[antoshkka at gmail dot com]

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

            Bug ID: 109931
           Summary: Knowledge on literal not used in optimization
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Function for comparing a lower-cased string with runtime string of known size:


constexpr bool ICaseEqualLowercase(const char* lowercase, const char* y,
                                   unsigned size) noexcept {
    constexpr char kLowerToUpperMask = static_cast<char>(~unsigned{32});
    for (unsigned i = 0; i < size; ++i) {
        const auto lowercase_c = lowercase[i];
        if (lowercase_c != y[i]) {
            if (!('a' <= lowercase_c && lowercase_c <= 'z') ||
                (lowercase_c & kLowerToUpperMask) != y[i]) {
                return false;
            }
        }
    }

    return true;
}
bool test2(const char* y) {
    return ICaseEqualLowercase("hello", y, 5);
}


With GCC trunk and -O2 flags the GCC fails to understand that all the
characters of `lowercase` are lowercase ASCII and the expression `!('a' <=
lowercase_c && lowercase_c <= 'z')` is always `false`.

Because of that, additional instructions in loop are emitted:
        lea     esi, [rdx-97]
        cmp     sil, 25
        ja      .L6


Godbolt playground: https://godbolt.org/z/xrc1T4oeW

[Bug tree-optimization/109931] Knowledge on literal not used in optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
But that's because nothing in the function asserts this?  Without fully
specializing and unrolling on the constant "hello" argument at least.

[Bug tree-optimization/109931] Knowledge on literal not used in optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is another case of the missing range info for loads from read-only
constants.

[Bug tree-optimization/109931] Knowledge on literal not used in optimization

[antoshkka at gmail dot com]

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

--- Comment #3 from Antony Polukhin <antoshkka at gmail dot com> ---
> But that's because nothing in the function asserts this?  Without fully
> specializing and unrolling on the constant "hello" argument at least.

Yes, I was hoping for that unrolling to happen

Probably a more simplified case:


constexpr bool EqualICase(const char* lowercase, const char* y) noexcept {
    for (;;) {
        const auto lowercase_c = *lowercase;
        if (!lowercase_c) return true;
        if (lowercase_c != *y) {
            return false;
        }
        ++lowercase;
        ++y;
    }
}
bool test2(const char* y) {
    return EqualICase("he", y);
}

With range info for loads from read-only constants I'd expect this to become
just a

test2(char const*):
        cmp     BYTE PTR [rdi], 104
        jne     .L3
        cmp     BYTE PTR [rdi+1], 101
        sete    al
        ret
.L3:
        xor     eax, eax
        ret


rather than a fair loop with checks for \0

Godbolt: https://godbolt.org/z/z6rTYEzWx

[Bug tree-optimization/109931] Knowledge on literal not used in optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There is another bug about this.
In this case we know that bit 5 is set for the range ['a','z'] .