How to avoid some built-in expansions in gcc?

How to avoid some built-in expansions in gcc?

[Georg-Johann Lay]

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

Re: How to avoid some built-in expansions in gcc?

[Jonathan Wakely]

On Fri, 31 May 2024 at 14:52, 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).

Did you try -fno-builtin-isinff ?

Re: How to avoid some built-in expansions in gcc?

[Georg-Johann Lay]

Am 31.05.24 um 15:56 schrieb Jonathan Wakely:
> On Fri, 31 May 2024 at 14:52, 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).
> 
> Did you try -fno-builtin-isinff ?

Are you saying that setting that option in, say, 
gcc/common/config/avr/avr-common.cc is the way to go?

Johann

Re: How to avoid some built-in expansions in gcc?

[Jonathan Wakely]

On Fri, 31 May 2024 at 15:53, Georg-Johann Lay <avr@gjlay.de> wrote:
>
>
>
> Am 31.05.24 um 15:56 schrieb Jonathan Wakely:
> > On Fri, 31 May 2024 at 14:52, 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).
> >
> > Did you try -fno-builtin-isinff ?
>
> Are you saying that setting that option in, say,
> gcc/common/config/avr/avr-common.cc is the way to go?

Ah, I didn't realise you meant permanently disable them, by default,
not just for a given compilation.

Re: How to avoid some built-in expansions in gcc?

[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?  It should define the optimization rules, and those should allow it to bias towards small code rather than fast big code.

	paul

Re: How to avoid some built-in expansions in gcc?

[Georg-Johann Lay]

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

Re: How to avoid some built-in expansions in gcc?

[Paul Koning]

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

	paul

Re: How to avoid some built-in expansions in gcc?

[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 

>    paul
> 

Re: How to avoid some built-in expansions in gcc?

[Georg-Johann Lay]

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?

I also looked into patching options, but there is no way to hook in, or 
at least I did not find how to use targetm.handle_option or an 
appropriate place to call disable_builtin_function; it's all baken into 
the C front without any hook opportunity.

Johann

Re: How to avoid some built-in expansions in gcc?

[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 

> I also looked into patching options, but there is no way to hook in, or at least I did not find how to use targetm.handle_option or an appropriate place to call disable_builtin_function; it's all baken into the C front without any hook opportunity.
> 
> Johann
> 
> 

Re: How to avoid some built-in expansions in gcc?

[Georg-Johann Lay]

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.

How would I go about disabling / bypassing non-const folds from ctype.h 
and the many others?

Johann

Re: 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

Re: How to avoid some built-in expansions in gcc?

[Michael Matz]

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

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.

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

Re: How to avoid some built-in expansions in gcc?

[Richard Biener]

> Am 04.06.2024 um 16:56 schrieb Michael Matz <matz@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.

Re: How to avoid some built-in expansions in gcc?

[Michael Matz]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

Hello,

On Tue, 4 Jun 2024, Richard Biener wrote:

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

Hmm, true.  Not expanding inline is orthogonal strictly speaking ...

> which is worse for optimization than just not inline expanding it.

... but on AVR expanding inline is probably worse than that lost 
knowledge.  So yeah, ideally we would devise a (simple/reasonable) way to 
at least disable inline expansion, without making it non-builtin.

(Well, and without reverse-recognition of isfinite-like idioms in the 
sources.  That's orthogonal as well.)


Ciao,
Michael.

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

Re: How to avoid some built-in expansions in gcc?

[Jakub Jelinek]

On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote:
> (Well, and without reverse-recognition of isfinite-like idioms in the 
> sources.  That's orthogonal as well.)

Why?  If isfinite is better done by a libcall, why isn't isfinite-like
idiom also better done as a libcall?

	Jakub

Re: How to avoid some built-in expansions in gcc?

[Michael Matz]

Hello,

On Tue, 4 Jun 2024, Jakub Jelinek wrote:

> On Tue, Jun 04, 2024 at 07:43:40PM +0200, Michael Matz via Gcc wrote:
> > (Well, and without reverse-recognition of isfinite-like idioms in the 
> > sources.  That's orthogonal as well.)
> 
> Why?  If isfinite is better done by a libcall, why isn't isfinite-like
> idiom also better done as a libcall?

It is.  I was just trying to avoid derailing the discussion for finding an 
immediately good solution by searching for the perfect solution.  Idiom 
finding simply is completely independend from the posed problem that 
Georg-Johann has, which remains unsolved AFAICS, as using 
fno-builtin-foobar has its own (perhaps mere theoretical for AVR) 
problems.


Ciao,
Michael.

Re: How to avoid some built-in expansions in gcc?

[David Brown]

On 04/06/2024 19:43, Michael Matz via Gcc wrote:
> Hello,
> 
> On Tue, 4 Jun 2024, Richard Biener wrote:
> 
>>>> 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
> 
> Hmm, true.  Not expanding inline is orthogonal strictly speaking ...
> 
>> which is worse for optimization than just not inline expanding it.
> 
> ... but on AVR expanding inline is probably worse than that lost
> knowledge.  So yeah, ideally we would devise a (simple/reasonable) way to
> at least disable inline expansion, without making it non-builtin.
> 

The ideal here would be to have some way to tell gcc that a given 
function has the semantics of a different function.  For example, a 
programmer might have several implementations of "memcpy" that are 
optimised for different purposes based on the size or alignment of the 
arguments.  Maybe some of these are written with inline assembly or work 
in a completely different way (I've used DMA on a microcontroller for 
the purpose).  If you could tell the compiler that the semantic 
behaviour and results were the same as standard memcpy(), that could 
lead to optimisations.

Then you could declare your "isinf" function with 
__attribute__((semantics_of(__builtin_isinf))).

And the feature could be used in any situation where you can write a 
function in a simple, easy-to-analyse version and a more efficient but 
opaque version.

Re: How to avoid some built-in expansions in gcc?

[Michael Matz]

Hey,

On Wed, 5 Jun 2024, David Brown wrote:

> The ideal here would be to have some way to tell gcc that a given 
> function has the semantics of a different function.  For example, a 
> programmer might have several implementations of "memcpy" that are 
> optimised for different purposes based on the size or alignment of the 
> arguments.  Maybe some of these are written with inline assembly or work 
> in a completely different way (I've used DMA on a microcontroller for 
> the purpose).  If you could tell the compiler that the semantic 
> behaviour and results were the same as standard memcpy(), that could 
> lead to optimisations.
> 
> Then you could declare your "isinf" function with 
> __attribute__((semantics_of(__builtin_isinf))).
> 
> And the feature could be used in any situation where you can write a 
> function in a simple, easy-to-analyse version and a more efficient but 
> opaque version.

Hmm, that actually sounds like a useful feature.  There are some details 
to care for, like what to do with arguments: e.g. do they need to have the 
same types as the referred builtin, only compatible ones, or even just 
convertible ones, and suchlike, but yeah, that sounds nice.


Ciao,
Michael.

Re: How to avoid some built-in expansions in gcc?

[Richard Biener]

> Am 05.06.2024 um 16:08 schrieb Michael Matz <matz@suse.de>:
> 
> Hey,
> 
>> On Wed, 5 Jun 2024, David Brown wrote:
>> 
>> The ideal here would be to have some way to tell gcc that a given
>> function has the semantics of a different function.  For example, a
>> programmer might have several implementations of "memcpy" that are
>> optimised for different purposes based on the size or alignment of the
>> arguments.  Maybe some of these are written with inline assembly or work
>> in a completely different way (I've used DMA on a microcontroller for
>> the purpose).  If you could tell the compiler that the semantic
>> behaviour and results were the same as standard memcpy(), that could
>> lead to optimisations.
>> 
>> Then you could declare your "isinf" function with
>> __attribute__((semantics_of(__builtin_isinf))).
>> 
>> And the feature could be used in any situation where you can write a
>> function in a simple, easy-to-analyse version and a more efficient but
>> opaque version.
> 
> Hmm, that actually sounds like a useful feature.  There are some details
> to care for, like what to do with arguments: e.g. do they need to have the
> same types as the referred builtin, only compatible ones, or even just
> convertible ones, and suchlike, but yeah, that sounds nice.

There’s the difficulty to avoid having GCC replace it with a semantically equivalent call (that would be no longer optimized).  That is, your intent is to enable a subset of optimizations only enabled by denoting the semantic equivalence.  That subset at least needs documenting.

Richard 

> 
> Ciao,
> Michael.