On 04/06/2024 19:43, Michael Matz via Gcc wrote:
Hello,
On Tue, 4 Jun 2024, Richard Biener wrote:
A pragmatic solution might be a new target hook, indicating a specified
builtin is not to be folded into an open-coded form.
Well, that's what the mechanism behind -fno-builtin-foobar is supposed to
be IMHO. Hopefully the newly added additional mechanism using optabs and
ifns (instead of builtins) heeds it.
-fno-builtin makes GCC not know semantics of the functions called
Hmm, true. Not expanding inline is orthogonal strictly speaking ...
which is worse for optimization than just not inline expanding it.
... but on AVR expanding inline is probably worse than that lost
knowledge. So yeah, ideally we would devise a (simple/reasonable) way to
at least disable inline expansion, without making it non-builtin.
The ideal here would be to have some way to tell gcc that a given
function has the semantics of a different function. For example, a
programmer might have several implementations of "memcpy" that are
optimised for different purposes based on the size or alignment of the
arguments. Maybe some of these are written with inline assembly or work
in a completely different way (I've used DMA on a microcontroller for
the purpose). If you could tell the compiler that the semantic
behaviour and results were the same as standard memcpy(), that could
lead to optimisations.
Then you could declare your "isinf" function with
__attribute__((semantics_of(__builtin_isinf))).
And the feature could be used in any situation where you can write a
function in a simple, easy-to-analyse version and a more efficient but
opaque version.
