> Am 01.06.2024 um 17:41 schrieb Georg-Johann Lay <a...@gjlay.de>:
>
>
>
> Am 31.05.24 um 22:12 schrieb Richard Biener:
>>>> Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay <a...@gjlay.de>:
>>>
>>>
>>>
>>> Am 31.05.24 um 19:32 schrieb Richard Biener:
>>>>>> Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc <gcc@gcc.gnu.org>:
>>>>>
>>>>>
>>>>>
>>>>>> On May 31, 2024, at 11:06 AM, Georg-Johann Lay <a...@gjlay.de> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 31.05.24 um 17:00 schrieb Paul Koning:
>>>>>>>>> On May 31, 2024, at 9:52 AM, Georg-Johann Lay <a...@gjlay.de> 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.
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.
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?
Richard
>
> Johann
