[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[felix.von.s at posteo dot de]

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

felix <felix.von.s at posteo dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |felix.von.s at posteo dot de

--- Comment #1 from felix <felix.von.s at posteo dot de> ---
> Unfortunately the macro trick is arcane and has one potential issue: the compiler may actually generate code to check `cond` at run-time if it cannot deduce that it's a pure function.

Oh, don't worry; the Other Compiler’s solution isn’t perfect either :)

    __builtin_assume(({ for (;;) {}; 1; }));

This emits code for the infinite loop. For a less silly example:

    __attribute__((__const__,__always_inline__))
    inline static int is_pow2(unsigned j) {
        __auto_type i = j;

        for (int c = 0; c < CHAR_BIT * sizeof(i); ++c) {
            i = (i >> 1) | ((i & 1) << (CHAR_BIT * sizeof(i) - 1));
            if (i == 1)
                break;
        }

        return i == 1;
    }

    int foo(void) {
        extern unsigned bar(void);
        __auto_type x = bar();

        __builtin_assume(is_pow2(x));

        return __builtin_popcount(x);
    }

This will also emit code for the loop, even though the result is not used at
runtime. The code is not very idiomatic, but I don’t believe it’s wrong either:
the __attribute__((const)) on is_pow2 I consider correct, because the side
effects do not escape the function.

If anyone takes this up, it would be nice if GCC at least did not outright
pessimise such code.

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[felix.von.s at posteo dot de]

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

--- Comment #2 from felix <felix.von.s at posteo dot de> ---
I realised recently that this is already expressible:

#define __builtin_assume(expr) \
    (__builtin_pure_p(expr) \
        ? ((expr) \
            ? (void) 0 \
            : __builtin_unreachable()) \
        : (void) 0 /* XXX: warn about side effects */)

where __builtin_pure_p has the same definition that I gave under PR 6906:

#define __builtin_pure_p(expr) \
    (__builtin_object_size(((void) (expr), ""), 2))

As for the corner case I gave earlier, GCC manages to optimise the is_pow2 loop
away at -O2 and -O3 (though not entirely at -O1), and it apparently considers
statement-expressions that contain more than one statement, or any kind of
loop, to have side effects. One can always check __OPTIMIZE__ to prevent
spurious code from being generated at -O0. So this solution apparently performs
no worse :)

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-11-24
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |ktkachov at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from ktkachov at gcc dot gnu.org ---
We've received requests from some users for this builtin as well. Given the new
ranger infrastructure, would it be able to make use of the semantics of such a
builtin in a useful way? (It'd be good to see GCC eliminate some redundant
extensions, maybe threading opportunities could be improved etc)

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Now the assume for C++23's assume attribute has been added, adding this builtin
should be straight forward I think.

Because the builtin is exactly the same as the attribute in that the expression
supplied to the builtin would not execute for side effects.

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Just use the attribute, I'd prefer not to add the builtin, especially when
clang makes it pretty much useless (as it warns about side-effects in the arg,
doesn't evaluate them and ignores it completely in that case).

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So even though clang/LLVM has not implement the attribute yet
(https://github.com/llvm/llvm-project/pull/81014), adding another extension is
not a good idea for GCC so closing as won't fix. There is a reason why this got
standarized is so it can be implemented in a cross compiler way.

Also the builtin has an odd definition when it comes to the whole no side
effects (though the attribute has that, it is not directly part of the a
function call).