public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Georg-Johann Lay <avr@gjlay.de>
To: Richard Biener <richard.guenther@gmail.com>,
	Paul Koning <paulkoning@comcast.net>
Cc: gcc@gcc.gnu.org
Subject: Re: How to avoid some built-in expansions in gcc?
Date: Fri, 31 May 2024 20:56:18 +0200	[thread overview]
Message-ID: <f26878c9-8c84-43d1-8237-b626141fb954@gjlay.de> (raw)
In-Reply-To: <6393F557-ED56-4EA1-A45C-FD99C1AE7F53@gmail.com>



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



  reply	other threads:[~2024-05-31 18:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31 13:52 Georg-Johann Lay
2024-05-31 13:56 ` Jonathan Wakely
2024-05-31 14:53   ` Georg-Johann Lay
2024-05-31 14:53     ` Jonathan Wakely
2024-05-31 15:00 ` Paul Koning
2024-05-31 15:06   ` Georg-Johann Lay
2024-05-31 15:23     ` Paul Koning
2024-05-31 17:32       ` Richard Biener
2024-05-31 18:56         ` Georg-Johann Lay [this message]
2024-05-31 20:12           ` Richard Biener
2024-06-01 15:41             ` Georg-Johann Lay
2024-06-01 17:30               ` Richard Biener
2024-06-04 14:55                 ` Michael Matz
2024-06-04 16:43                   ` Richard Biener
2024-06-04 17:43                     ` Michael Matz
2024-06-04 17:48                       ` Jakub Jelinek
2024-06-05 13:52                         ` Michael Matz
2024-06-05 13:33                       ` David Brown
2024-06-05 14:08                         ` Michael Matz
2024-06-05 14:16                           ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f26878c9-8c84-43d1-8237-b626141fb954@gjlay.de \
    --to=avr@gjlay.de \
    --cc=gcc@gcc.gnu.org \
    --cc=paulkoning@comcast.net \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).