* [Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
[not found] <bug-79469-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-27 17:53 ` felix.von.s at posteo dot de
2020-04-17 11:43 ` felix.von.s at posteo dot de
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: felix.von.s at posteo dot de @ 2020-03-27 17:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
[not found] <bug-79469-4@http.gcc.gnu.org/bugzilla/>
2020-03-27 17:53 ` [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
@ 2020-04-17 11:43 ` felix.von.s at posteo dot de
2021-11-24 16:27 ` ktkachov at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: felix.von.s at posteo dot de @ 2020-04-17 11:43 UTC (permalink / raw)
To: gcc-bugs
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 :)
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
[not found] <bug-79469-4@http.gcc.gnu.org/bugzilla/>
2020-03-27 17:53 ` [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
2020-04-17 11:43 ` felix.von.s at posteo dot de
@ 2021-11-24 16:27 ` ktkachov at gcc dot gnu.org
2022-10-26 19:44 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2021-11-24 16:27 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
[not found] <bug-79469-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2021-11-24 16:27 ` ktkachov at gcc dot gnu.org
@ 2022-10-26 19:44 ` pinskia at gcc dot gnu.org
2022-10-26 19:52 ` jakub at gcc dot gnu.org
2024-03-05 0:53 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-26 19:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
[not found] <bug-79469-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2022-10-26 19:44 ` pinskia at gcc dot gnu.org
@ 2022-10-26 19:52 ` jakub at gcc dot gnu.org
2024-03-05 0:53 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-10-26 19:52 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
[not found] <bug-79469-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2022-10-26 19:52 ` jakub at gcc dot gnu.org
@ 2024-03-05 0:53 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-05 0:53 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 6+ messages in thread