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 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
gcc-14-20240601 is now available
Snapshot gcc-14-20240601 is now available on https://gcc.gnu.org/pub/gcc/snapshots/14-20240601/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 14 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-14 revision d7f42794d94e5a26f396253b1698ea1930337df3 You'll find: gcc-14-20240601.tar.xz Complete GCC SHA256=2aae07470ed3d3c053f223b6dde655b995905327dd6108e41a0127bca9f61040 SHA1=0e0600b5d46aa1d7c60a8876177f00af8112d742 Diffs from 14-20240525 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-14 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
