[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79469 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- 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).
[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79469 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79469 --- Comment #4 from Andrew Pinski --- 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79469 --- Comment #2 from felix --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79469
felix changed:
What|Removed |Added
CC||felix.von.s at posteo dot de
--- Comment #1 from felix ---
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79469 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Severity|normal |enhancement
