How to avoid some built-in expansions in gcc?

[Richard Biener]

> Am 01.06.2024 um 17:41 schrieb Georg-Johann Lay <avr@gjlay.de>:
> 
> 
> 
> Am 31.05.24 um 22:12 schrieb Richard Biener:
>>>> Am 31.05.2024 um 20:56 schrieb Georg-Johann Lay <avr@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 <avr@gjlay.de> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Am 31.05.24 um 17:00 schrieb Paul Koning:
>>>>>>>>> On May 31, 2024, at 9:52 AM, Georg-Johann Lay <avr@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