public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Bernd Schmidt <bschmidt@redhat.com>
Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com
Subject: Re: [PATCH 0/9] separate shrink-wrapping
Date: Wed, 08 Jun 2016 15:16:00 -0000	[thread overview]
Message-ID: <20160608151645.GA13163@gate.crashing.org> (raw)
In-Reply-To: <a576ff9b-a3c7-d4c6-cba7-73edc07fd428@redhat.com>

On Wed, Jun 08, 2016 at 01:55:55PM +0200, Bernd Schmidt wrote:
> On 06/08/2016 03:47 AM, Segher Boessenkool wrote:
> >This patch series introduces separate shrink-wrapping.
> [...]
> >The next six patches are to prevent later passes from mishandling the
> >epilogue instructions that now appear before the epilogue: mostly, you
> >cannot do much to instructions with a REG_CFA_RESTORE note without
> >confusing dwarf2cfi.  The cprop one is for prologue instructions.
> 
> I'll need a while to sort out my thoughts about this. On the whole I 
> like having the ability to do this, but I'm worried about the fragility 
> it introduces in passes after shrink-wrapping.

On the plus side I should have caught most of it now.  And the failures
are rarely silent, they show up during compilation already.

Most of the problems are code changes the later passes want to do that
are valid an sich but that dwarf2cfi does not like, like not restoring
a callee-saved register before a noreturn call.  Those later patches
already know not to touch epilogue instructions, but only for the single
epilogue, not for instructions scattered throughout the whole function.

> Ideally we'd need an ix86 implementation for test coverage reasons.

Yes, but someone who knows the x86 backend well will have to write that.

> Is the usage of the word "concern" here standard for this kind of thing? 
> It seems odd somehow but maybe that's just me.

There is no standard naming for this as far as I know.  I'll gladly
use a better name anyone comes up with.


Segher

  parent reply	other threads:[~2016-06-08 15:16 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08  1:48 Segher Boessenkool
2016-06-08  1:48 ` [PATCH 2/9] cfgcleanup: Don't confuse CFI when -fshrink-wrap-separate Segher Boessenkool
2016-06-08  1:48 ` [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc Segher Boessenkool
2016-06-08  1:48 ` [PATCH 3/9] dce: Don't dead-code delete separately wrapped restores Segher Boessenkool
2016-06-08  1:53 ` [PATCH 6/9] sel-sched: Don't mess with register restores Segher Boessenkool
2016-06-08  1:53 ` [PATCH 4/9] regrename: Don't rename restores Segher Boessenkool
2016-06-08  1:54 ` [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped Segher Boessenkool
2016-06-08  9:18   ` Bernd Schmidt
2016-09-09 18:41     ` Jeff Law
2016-09-09 20:56       ` Segher Boessenkool
2016-09-09 23:12         ` Jeff Law
2016-09-10  6:59           ` Segher Boessenkool
2016-09-12 16:36             ` Jeff Law
     [not found]               ` <CAGWvny=fHHZtKF4_D2098+3PTPPzxtg3EjKDWHyJwUxz8g_tEA@mail.gmail.com>
     [not found]                 ` <CAGWvnymZVg_FR_PHqhwkgrAkHDntVMEiG4shfst_GA9OnZKvWg@mail.gmail.com>
     [not found]                   ` <CAGWvnykQ3oz0UpcF6U1WYivbJww65h2EH5n3FocQ8JGY9hrOrA@mail.gmail.com>
2016-09-12 17:04                     ` Jeff Law
2016-09-14 13:08               ` Segher Boessenkool
2016-09-14 13:18                 ` Bernd Schmidt
2016-09-14 14:01                   ` Segher Boessenkool
2016-09-14 14:54                     ` Bernd Schmidt
2016-09-14 16:33                       ` Segher Boessenkool
2016-09-14 19:10                       ` Jeff Law
2016-09-14 17:55                     ` Jeff Law
2016-09-14 19:13                       ` Segher Boessenkool
2016-09-14 19:36                         ` Jeff Law
2016-09-14 18:21                 ` Jeff Law
2016-09-14 19:13                   ` Segher Boessenkool
2016-09-14 19:38                     ` Jeff Law
2016-09-14 22:34                       ` Segher Boessenkool
2016-09-15 17:28                         ` Jeff Law
2016-09-19 17:11                       ` Segher Boessenkool
2016-09-14 20:04                     ` Jeff Law
2016-09-14 22:51                       ` Segher Boessenkool
2016-06-08  1:54 ` [PATCH 7/9] cprop: Leave RTX_FRAME_RELATED_P instructions alone Segher Boessenkool
2016-06-08  2:03 ` [PATCH 8/9] shrink-wrap: shrink-wrapping for separate concerns Segher Boessenkool
2016-07-15 12:42   ` Bernd Schmidt
2016-07-18 16:34     ` Segher Boessenkool
2016-07-18 17:03       ` Bernd Schmidt
2016-07-19 14:46         ` Segher Boessenkool
2016-07-19 14:49           ` Bernd Schmidt
2016-07-19 15:35             ` Segher Boessenkool
2016-07-20 11:23               ` Bernd Schmidt
2016-07-20 15:06                 ` Segher Boessenkool
2016-06-08  2:04 ` [PATCH 9/9] rs6000: Separate shrink-wrapping Segher Boessenkool
2016-06-08 11:56 ` [PATCH 0/9] separate shrink-wrapping Bernd Schmidt
2016-06-08 12:45   ` Eric Botcazou
2016-06-08 15:16   ` Segher Boessenkool [this message]
2016-06-08 16:43     ` Bernd Schmidt
2016-06-08 17:26       ` Segher Boessenkool
2016-06-29 23:06         ` Bernd Schmidt
2016-06-29 23:24           ` Segher Boessenkool
2016-07-04  8:57             ` Segher Boessenkool
2016-06-14 21:24       ` Segher Boessenkool
2016-07-08 10:42         ` Bernd Schmidt
2016-07-08 12:11           ` Segher Boessenkool
2016-07-08 13:16             ` David Malcolm
2016-07-08 13:45               ` Segher Boessenkool
2016-07-08 14:35                 ` Bill Schmidt
2016-06-09 16:12 ` Jeff Law
2016-06-09 19:57   ` Segher Boessenkool
2016-06-28  0:22 ` PING " Segher Boessenkool
2016-07-07 10:16   ` PING x2 " Segher Boessenkool

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=20160608151645.GA13163@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=bschmidt@redhat.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).