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