public inbox for
 help / color / mirror / Atom feed
From: Richard Biener <>
To: Alexandre Oliva <>
Subject: Re: [RFC] Introduce -finline-memset-loops
Date: Mon, 16 Jan 2023 08:26:16 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sat, Jan 14, 2023 at 2:55 AM Alexandre Oliva <> wrote:
> Hello, Richard,
> Thank you for the feedback.
> On Jan 12, 2023, Richard Biener <> wrote:
> > On Tue, Dec 27, 2022 at 5:12 AM Alexandre Oliva via Gcc-patches
> > <> wrote:
> >> This patch extends the memset expansion to start with a loop, so as to
> >> still take advantage of known alignment even with long lengths, but
> >> without necessarily adding store blocks for every power of two.
> > I wonder if that isn't better handled by targets via the setmem pattern,
> That was indeed where I started, but then I found myself duplicating the
> logic in try_store_by_multiple_pieces on a per-target basis.
> Target-specific code is great for tight optimizations, but the main
> purpose of this feature is not an optimization.  AFAICT it actually
> slows things down in general (due to code growth, and to conservative
> assumptions about alignment), except perhaps for some microbenchmarks.
> It's rather a means to avoid depending on the C runtime, particularly
> due to compiler-introduced memset calls.

OK, that's what I guessed but you didn't spell out.  So does it make sense
to mention -ffreestanding in the docs at least?  My fear is that we'd get
complaints that -O3 -finline-memset-loops turns nicely optimized memset
loops into dumb ones (via loop distribution and then stupid re-expansion).
So does it also make sense to turn off -floop-distribute-patterns[-memset]
with -finline-memset-loops?

> My initial goal was to be able to show that inline expansion would NOT
> bring about performance improvements, but performance was not the
> concern that led to the request.
> If the approach seems generally acceptable, I may even end up extending
> it to other such builtins.  I have a vague recollection that memcmp is
> also an issue for us.

The C/C++ runtime produce at least memmove, memcpy and memcmp as well.
In this respect -finline-memset-loops is too specific and to avoid an explosion
in the number of command line options we should try to come up with sth
better?  -finline-all-stringops[={memset,memcpy,...}] (just like x86 has

> > like x86 has the stringop inline strathegy.  What is considered acceptable
> > in terms of size or performance will vary and I don't think there's much
> > room for improvements on this generic code support?
> *nod* x86 is quite finely tuned already; I suppose other targets may
> have some room for additional tuning, both for performance and for code
> size, but we don't have much affordance for avoiding builtin calls to
> the C runtime, which is what this is about.
> Sometimes disabling loop distribution is enough to accomplish that, but
> in some cases GNAT itself resorts to builtin memset calls, in ways that
> are not so easy to avoid, and that would ultimately amount to expanding
> memset inline, so I figured we might as well offer that as a general
> feature, for users to whom this matters.
> Is (optionally) tending to this (uncommon, I suppose) need (or
> preference?) not something GCC would like to do?

Sure, I think for the specific intended purpose that would be fine.  It should
also only apply to __builtin_memset calls, not to memset calls from user code?


> --
> Alexandre Oliva, happy hacker      
>    Free Software Activist                       GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about <>

  parent reply	other threads:[~2023-01-16  7:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-27  4:02 Alexandre Oliva
2023-01-12 13:18 ` Richard Biener
2023-01-14  1:54   ` Alexandre Oliva
2023-01-14  2:12     ` Paul Koning
2023-01-14  3:21       ` Alexandre Oliva
2023-01-16  7:26     ` Richard Biener [this message]
2023-01-19 11:25       ` Alexandre Oliva
2023-01-19 11:58         ` Richard Biener
2023-06-02 10:11         ` Alexandre Oliva
2023-06-02 14:58           ` Fangrui Song
2023-06-23  2:23           ` Introduce -finline-stringops (was: Re: [RFC] Introduce -finline-memset-loops) Alexandre Oliva
2023-09-15  7:59             ` Introduce -finline-stringops Alexandre Oliva
2023-09-21  6:52               ` [PATCH v2] " Alexandre Oliva
2023-09-23  5:56                 ` [PATCH v3] " Alexandre Oliva
2023-11-20 12:51                   ` Alexandre Oliva
2023-11-20 13:49                     ` Richard Biener
2023-12-11 18:43             ` Introduce -finline-stringops (was: Re: [RFC] Introduce -finline-memset-loops) Sam James
2023-12-12  1:42               ` Introduce -finline-stringops Alexandre Oliva

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \

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