> Am 04.06.2024 um 16:56 schrieb Michael Matz <m...@suse.de>:
>
> Hello,
>
> On Sat, 1 Jun 2024, Richard Biener via Gcc wrote:
>
>>>>> 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.
>>
>> The idea is that isdigit() || isalpha() or similar optimize without
>> special casing the builtins.
>>
>>> How would I go about disabling / bypassing non-const folds from ctype.h and
>>> the many others?
>>
>> I think this mostly shows we lack late recognition of open-coded isdigit
>> and friends, at least for the targets where inlining them is not
>> profitable.
>>
>> 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 which is
worse for optimization than just not inline expanding it.
Richard
>> A good solution would base this on (size) costs, the perfect solution
>> would re-discover the builtins late and undo inlining that didn’t turn
>> out to enable further simplification.
>>
>> How is inlined isdigit bad on AVR? Is a call really that cheap
>> considering possible register spilling around it?
>
> On AVR with needing to use 8bit registers to do everything? I'm pretty
> sure the call is cheaper, yeah :)
>
>
> Ciao,
> Michael.
