public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "Moritz Strübe" <moritz.struebe@redheads.de>
Cc: Freddie Chopin <freddie_chopin@op.pl>,  gcc@gcc.gnu.org
Subject: Re: size of exception handling
Date: Tue, 12 May 2020 13:29:16 +0200	[thread overview]
Message-ID: <87h7wl9ysz.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <7e904ffa-da24-44d7-307f-cc3f3f5f474d@redheads.de> ("Moritz \=\?utf-8\?Q\?Str\=C3\=BCbe\=22's\?\= message of "Tue, 12 May 2020 13:17:33 +0200")

* Moritz Strübe:

>> Would you use it if switching from -fno-exceptions to this new
>> approach resulted in an immediate 20% code size increase, without
>> actually using the new error handling feature at all?  What about
>> 10%?
>
> I don't think that it will be that much.

Why?  Have you simulated the code size changes?  I actually ran some
experiments.

> Exceptions are critical errors you need to handle anyway. Thus the
> code size should not increase as the error-handling code should
> already be there.  I can really recommend Herb's talk:
> https://www.youtube.com/watch?v=ARYP83yNAWk , where also talks about
> reducing RTTI overhead and making the C++-lib mostly exception free.

I think the proponents generally underestimate how many functions would
need to change their signature so that they can propagate errors using
the new mechanism.  This leads to very optimistic estimations on size
impact.

> In that talk he mentions that it would be possible using some CPU-Bit
> to return the state.

That's quite hard for us because of the stack protector.  It's unclear
if using the flag is actually beneficial from a code site perspective.
Obviously it depends on the ration between functions and call sites.

Thanks,
Florian


  reply	other threads:[~2020-05-12 11:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11  8:14 performance " Thomas Neumann
2020-05-11 10:40 ` Florian Weimer
2020-05-11 13:59   ` Thomas Neumann
2020-05-11 14:22     ` Florian Weimer
2020-05-11 15:14     ` size of exception handling (Was: performance of exception handling) Moritz Strübe
2020-05-12  7:20       ` Freddie Chopin
2020-05-12  7:47         ` Oleg Endo
2020-05-13  9:13           ` Jonathan Wakely
2020-05-12  9:16         ` size of exception handling Florian Weimer
2020-05-12  9:44           ` Freddie Chopin
2020-05-12 11:11             ` Jonathan Wakely
2020-05-12 11:17             ` Moritz Strübe
2020-05-12 11:29               ` Florian Weimer [this message]
2020-05-12 12:01                 ` Moritz Strübe
2020-05-12 11:07         ` size of exception handling (Was: performance of exception handling) Jonathan Wakely
2020-05-12 20:56           ` Freddie Chopin
2020-05-12 22:39             ` Jonathan Wakely
2020-05-12 22:48               ` Jonathan Wakely
2020-05-13  8:04                 ` David Brown
2020-05-12  9:03       ` size of exception handling Florian Weimer
2020-05-11 14:36   ` performance " David Edelsohn
2020-05-11 14:52     ` Florian Weimer
2020-05-11 15:12       ` David Edelsohn
2020-05-11 15:24         ` Florian Weimer
2020-05-12  6:08     ` Thomas Neumann
2020-05-12  7:15       ` Richard Biener
2020-05-12  7:30         ` Thomas Neumann
2020-05-12  9:01       ` Richard Sandiford
2020-05-13  1:13         ` Thomas Neumann

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=87h7wl9ysz.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=freddie_chopin@op.pl \
    --cc=gcc@gcc.gnu.org \
    --cc=moritz.struebe@redheads.de \
    /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).