[Bug tree-optimization/103565] New: GCC emits more assembly than clang for carry flag

[Bug tree-optimization/103565] New: GCC emits more assembly than clang for carry flag

[unlvsur at live dot com]

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

            Bug ID: 103565
           Summary: GCC emits more assembly than clang for carry flag
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

I tried both examples. One emulation with the pattern. Another is with the x86
intrinsic. GCC emits more instructions than clang.

https://godbolt.org/z/d15WEY85T
https://godbolt.org/z/cob36P8nz

Also can GCC be able to understand the pattern of add_carry_pattern just like
it understands std::rotl? 
https://github.com/gcc-mirror/gcc/blob/8d4ef2299cbf9517877dab60d48f34835758a6ee/libstdc%2B%2B-v3/include/std/bit#L135

template<typename T>
inline constexpr bool add_carry_pattern(bool carry,T a,T b,T& out) noexcept
{
        T temp{carry+a};
        out=temp+b;
        return (out < b) | (temp < a);
}

So we do not need that intrinsic anymore and the whole thing can be optimized
at SSA level, rather than RTL level??

[Bug tree-optimization/103565] GCC emits more assembly than clang for carry flag

[unlvsur at live dot com]

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

--- Comment #1 from cqwrteur <unlvsur at live dot com> ---
https://godbolt.org/z/bGfY6zh9x

#include<concepts>

template<std::unsigned_integral T>
inline constexpr bool add_carry_pattern(bool carry,T a,T b,T& out) noexcept
{
        T temp{carry+a};
        out=temp+b;
        return (out < b) | (temp < a);
}

Well. it should be restricted with unsigned_integral.

[Bug tree-optimization/103565] GCC emits more assembly than clang for carry flag

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The difference is just argument and return register differences (and maybe a
register allocation issue).
That is the extra instructions are:
for add_carry_pattern_test:
        movzx   edi, dil
        mov     r8, rcx
        xor     ecx, ecx

for add_carry_x86_intrinsics:
        movzx   edi, dil

[Bug target/103565] GCC emits more assembly than clang for carry flag

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
          Component|tree-optimization           |target

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The tree level looks good:
  _6 = (long long unsigned int) carry_1(D);
  _13 = .ADD_OVERFLOW (a_3(D), _6);
  temp_7 = REALPART_EXPR <_13>;
  _14 = IMAGPART_EXPR <_13>;
  _15 = .ADD_OVERFLOW (b_4(D), temp_7);
  _8 = REALPART_EXPR <_15>;
  _16 = IMAGPART_EXPR <_15>;
  *out_5(D) = _8;
  _9 = _16 != 0;
  _10 = _14 != 0;
  _11 = _9 | _10;

[Bug target/103565] GCC emits more assembly than clang for carry flag

[unlvsur at live dot com]

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

--- Comment #4 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Pinski from comment #3)
> The tree level looks good:
>   _6 = (long long unsigned int) carry_1(D);
>   _13 = .ADD_OVERFLOW (a_3(D), _6);
>   temp_7 = REALPART_EXPR <_13>;
>   _14 = IMAGPART_EXPR <_13>;
>   _15 = .ADD_OVERFLOW (b_4(D), temp_7);
>   _8 = REALPART_EXPR <_15>;
>   _16 = IMAGPART_EXPR <_15>;
>   *out_5(D) = _8;
>   _9 = _16 != 0;
>   _10 = _14 != 0;
>   _11 = _9 | _10;

so is that possible to understand the pattern of addcarry in C or C++ for GCC?
clang does that by adding new builtins but Jakub said pattern matching is
better since the compiler can optimize it later.

I think it is totally possible for using pattern matching instead of built-in.