> 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
> paul
>
