public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Ian Lance Taylor <iant@golang.org>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	"gofrontend-dev@googlegroups.com"
	<gofrontend-dev@googlegroups.com>,	Jan Hubicka <hubicka@ucw.cz>
Subject: Re: Patch RFC: disable block partitioning with split stack
Date: Fri, 09 Jun 2017 10:16:00 -0000	[thread overview]
Message-ID: <20170609101637.GC30427@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <CAOyqgcXZgv9a5b+ynC4nT_5S4bFfQQwdkg0OXpsrDeXgeRgY+Q@mail.gmail.com>

> This recent patch
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00518.html turned on
> block partitioning even when profiling is not enabled.  This can break

I am heading towards enabling block partitioning by default (because we now
have infrastructure to identify likely cold BBs), but I must admit I did
not notice I made it happen by that patch.  reorder_blocks_and_partition
is not enabled in opts.c but I see it is hidden within
common/config/i386/i386-common.c that I did not know even existed.

> code compiled with -fsplit-stack, if the cold partition calls a
> function that is not compiled with -fsplit-stack (such as a C library
> function).  The problem is that when the linker sees a split-stack
> function call a non-split-stack function, it adjusts the function
> header to request more stack space.  This doesn't work if the call is
> in the cold partition, as the linker doesn't know how to find the
> header to adjust.  You can see this by trying to build the Go library
> using the gold linker with this patch.

If code does not work, I wonder why we let user to overwrite the default
by hand? In other cases we drop the flag with inform message.

Also bb-reorder knows how to prevent landing pads to go to different sections,
so perhaps same machinery can be used to prevent splitting blocks having
calls that needs linker adjustments?

But if fixing this is involved, I am fine with how it is done in your patch.

Honza

  parent reply	other threads:[~2017-06-09 10:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-09  5:14 Ian Lance Taylor
2017-06-09 10:10 ` Richard Biener
2017-06-09 10:16 ` Jan Hubicka [this message]
2017-06-09 14:15   ` Ian Lance Taylor
2017-06-09 18:22     ` Jan Hubicka
2017-06-09 18:45       ` Ian Lance Taylor
2017-06-11  9:38         ` Jan Hubicka
2017-06-12  2:40           ` Ian Lance Taylor
2017-06-11 11:41         ` [PATCH] Fix new split-1.c testcase Segher Boessenkool
2017-06-12  2:38           ` Ian Lance Taylor
2017-06-12 10:38             ` Segher Boessenkool
2017-06-12 11:08               ` Paul Hua
2017-06-12 16:16               ` Ian Lance Taylor
2017-06-12 17:58                 ` 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=20170609101637.GC30427@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gofrontend-dev@googlegroups.com \
    --cc=iant@golang.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).