Am 31.05.24 um 22:12 schrieb Richard Biener:
Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay <[email protected]>:
Am 31.05.24 um 19:32 schrieb Richard Biener:
Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc <[email protected]>:
On May 31, 2024, at 11:06 AM, Georg-Johann Lay <[email protected]> wrote:
Am 31.05.24 um 17:00 schrieb Paul Koning:
On May 31, 2024, at 9:52 AM, Georg-Johann Lay <[email protected]> wrote:
What's the recommended way to stop built-in expansions in gcc?
For example, avr-gcc expands isinff() to a bloated version of an isinff()
implementation that's written in asm (PR115307).
Johann
Isn't that up to the target back end?
paul
Yes, that's the reason why it's a target PR.
My question is where/how to do it.
It's clear that twiddling the options works and is a simple and comprehensible
solution, but it seems a bit of a hack to me.
Johann
I haven't dug deep into this, but I would think at least part of the answer is
in the target cost functions. If those assign RTX cost according to size, then
the result would be the optimizer would favor smaller code. Right?
Does inline assembly expansion of builtins depend on target code supplying that
expansion? If so, the answer would be not to supply it, or at least not unless
asked for by an option. If it comes from common code, that's a different
matter, then perhaps there should be target hooks to let the target disallow or
discourage such expansion. I might want such a thing for pdp11 as well.
The function in question is folded to a comparison very early if the target
does not implement an optab for it. After that everything is lost. A
workaround is to define an optab but let expansion always FAIL.
Richard
You have a pointer how to define a target optab? I looked into optabs code but found
no appropriate hook. For isinf<mode> is seems is is enough to provide a
failing expander, but other functions like isnan don't have an optab entry, so there
is a hook mechanism to extend optabs?
Just add corresponding optabs for the missing cases (some additions are
pending, like isnornal). There’s no hook to prevent folding to FP compares nor
is that guarded by other means (like availability of native FP ops). Changing
the guards would be another reasonable option.
Richard
There are many other such folds, e.g. for isdigit(). The AVR libraries
have all this in hand-optimized assembly, and all these built-in
expansions are bypassing that. Open-coded C will never beat that
assemlbly code, at least not with the current GCC capabilities.
How would I go about disabling / bypassing non-const folds from ctype.h
and the many others?
Johann
