Re: How to avoid some built-in expansions in gcc?
> Am 05.06.2024 um 16:08 schrieb 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. 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.
Re: How to avoid some built-in expansions in gcc?
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?
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?
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?
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?
> Am 04.06.2024 um 16:56 schrieb Michael Matz : > > 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 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?
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 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?
> Am 01.06.2024 um 17:41 schrieb Georg-Johann Lay : > > > > Am 31.05.24 um 22:12 schrieb Richard Biener: Am 31.05.2024 um 20:56 schrieb 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 : > > > >> On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: >> >> >> >> Am 31.05.24 um 17:00 schrieb Paul Koning: > On May 31, 2024, at 9:52 AM, Georg-Johann Lay 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 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?
Am 31.05.24 um 22:12 schrieb Richard Biener: Am 31.05.2024 um 20:56 schrieb 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 : On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: Am 31.05.24 um 17:00 schrieb Paul Koning: On May 31, 2024, at 9:52 AM, Georg-Johann Lay 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 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?
> Am 31.05.2024 um 20:56 schrieb 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 : >>> >>> >>> On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: Am 31.05.24 um 17:00 schrieb Paul Koning: >>> On May 31, 2024, at 9:52 AM, Georg-Johann Lay 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 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?
Am 31.05.24 um 19:32 schrieb Richard Biener: Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc : On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: Am 31.05.24 um 17:00 schrieb Paul Koning: On May 31, 2024, at 9:52 AM, Georg-Johann Lay 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 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?
> Am 31.05.2024 um 17:25 schrieb Paul Koning via Gcc : > > > >> On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: >> >> >> >> Am 31.05.24 um 17:00 schrieb Paul Koning: > On May 31, 2024, at 9:52 AM, Georg-Johann Lay 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?
> On May 31, 2024, at 11:06 AM, Georg-Johann Lay wrote: > > > > Am 31.05.24 um 17:00 schrieb Paul Koning: >>> On May 31, 2024, at 9:52 AM, Georg-Johann Lay 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?
Am 31.05.24 um 17:00 schrieb Paul Koning: On May 31, 2024, at 9:52 AM, Georg-Johann Lay 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?
> On May 31, 2024, at 9:52 AM, Georg-Johann Lay 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?
On Fri, 31 May 2024 at 15:53, Georg-Johann Lay wrote: > > > > Am 31.05.24 um 15:56 schrieb Jonathan Wakely: > > On Fri, 31 May 2024 at 14:52, Georg-Johann Lay 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?
Am 31.05.24 um 15:56 schrieb Jonathan Wakely: On Fri, 31 May 2024 at 14:52, Georg-Johann Lay 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?
On Fri, 31 May 2024 at 14:52, Georg-Johann Lay 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 ?
How to avoid some built-in expansions in gcc?
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
