public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Santos <daniel.santos@pobox.com>
To: JonY <10walls@gmail.com>, Uros Bizjak <ubizjak@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	Jan Hubicka <hubicka@ucw.cz>,
	Sandra Loosemore <sandra@codesourcery.com>
Subject: Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues
Date: Fri, 10 Feb 2017 17:20:00 -0000	[thread overview]
Message-ID: <84cec90b-bdcd-2859-ac5a-9b34335982e5@pobox.com> (raw)
In-Reply-To: <e2d2f918-fcc4-be1d-7fa2-c589af2f157c@gmail.com>

On 02/10/2017 05:34 AM, JonY wrote:
> Hi,
>
> Thanks for the code size reduction patch, I have a few questions:

Thanks for your review!

> 1. How does code compiled with -moutline-msabi-xlogues interact with
> older code compiled without it? Are these only called on ABI transition?

These are only called in functions with the ABI transition from ms_abi 
to sysv_abi.  I'm not completely sure I understand the other question, 
however.  I haven't specifically tested linking two object files, one 
built with and without the option enabled, but I wouldn't expect it to 
produce any problems. Nor have I tested linking object files built with 
-moutline-msabi-xlogues with object files built with an older compiler.

> 2. Does this mean code compiled with -moutline-msabi-xlogues is not
> usable with older GCC? (no a problem, just something to note).

As above, I haven't tested this scenario, but I don't anticipate a 
problem other than general gcc version issues (like the default C++ ABI 
version, etc.). I can set up tests for this, but it will take me a 
little time. I used to have 12 gcc versions installed but I've rebuilt 
my system since then and I only have 4 now.  The nice thing about Gentoo 
is that you build every package yourself.  The bad thing about Gentoo is 
that you build every package yourself.

> 3. Is the old behavior (emit inline code) still default?

Yes.  And I believe that it was for this reason that Sandra (in CC) 
recommended renaming the feature to -m[no-]inline-msabi-xlogues with the 
default to "inline" since "inline" vs "no-inline" is the more common 
language used.  Also, the older behavior is still what is emitted for 
ABI transition functions under various conditions (below), some just 
because I haven't examined them yet.

+    if (!TARGET_SSE)
+      m->outline_ms_sysv = false;
+
+    /* Don't break hot-patched functions.  */
+    else if (ix86_function_ms_hook_prologue (current_function_decl))
+      m->outline_ms_sysv = false;
+
+    /* TODO: Cases not yet examined.  */
+    else if (TARGET_SEH)
+      disable_outline_msabi_xlogues (&warned_seh,
+				     "Structured Exception Handling (SEH)");
+    else if (crtl->calls_eh_return)
+      disable_outline_msabi_xlogues (NULL, "__builtin_eh_return");
+
+    else if (ix86_static_chain_on_stack)
+      disable_outline_msabi_xlogues (NULL, "static call chains");
+
+    else if (ix86_using_red_zone ())
+      disable_outline_msabi_xlogues (NULL, "red zones");
+
+    else if (flag_split_stack)
+      disable_outline_msabi_xlogues (NULL, "split stack");

In fact, DRAP used to be one of these cases and I only got that working with this last version of the patch set.

> mingw-w64 itself does not use any ms_abi/sysv_abi marked functions
> internally, so it should be unaffected. I don't think Cygwin uses any
> either, but I need to double check.

Of course, ms_abi is gcc's default on Windows so it would be sysv_abi 
functions.  I'm *guessing* that just about everything with Cygwin is 
built for Windows, but it would also make sense if (in some odd case) a 
binary built with sysv_abi is used by something and that library or 
program makes the ABI transition when using said hypothetical library.  
Even in these cases, I would not anticipate a problem, although any use 
of SEH would inhibit the optimization.  Of course, I haven't *tested* 
this, so I'm only speaking from what I know. :)

Daniel


  reply	other threads:[~2017-02-10 17:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07 18:34 Daniel Santos
2017-02-07 18:36 ` [PATCH 2/8] [i386] Add option -moutline-msabi-xlogues Daniel Santos
2017-02-08 23:28   ` Bernhard Reutner-Fischer
2017-02-10  4:43     ` Daniel Santos
2017-02-10 16:54       ` Sandra Loosemore
2017-02-10 17:32         ` Daniel Santos
2017-04-01 22:37         ` Daniel Santos
2017-02-07 18:36 ` [PATCH 3/8] [i386] Adds class xlouge_layout and new fields to struct machine_function Daniel Santos
2017-02-07 18:36 ` [PATCH 4/8] [i386] Modify ix86_save_reg to optionally omit stub-managed registers Daniel Santos
2017-02-07 18:37 ` [PATCH 5/8] [i386] Modify ix86_compute_frame_layout for foutline-msabi-xlogues Daniel Santos
2017-02-07 18:37 ` [PATCH 1/8] [i386] Minor refactoring Daniel Santos
2017-02-07 18:37 ` [PATCH 6/8] [i386] Add patterns and predicates foutline-msabi-xlouges Daniel Santos
2017-02-07 18:37 ` [PATCH 7/8] [i386] Add msabi pro/epilogue stubs to libgcc Daniel Santos
2017-02-10 10:32 ` [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues Uros Bizjak
2017-02-10 11:34   ` JonY
2017-02-10 17:20     ` Daniel Santos [this message]
2017-02-11  0:30       ` JonY
2017-02-11  7:24         ` Daniel Santos
2017-03-13 18:40         ` Daniel Santos
2017-03-10  4:42     ` Daniel Santos
2017-03-30 17:55       ` Daniel Santos
2017-03-30 23:28         ` JonY
2017-02-10 17:55   ` Daniel Santos

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=84cec90b-bdcd-2859-ac5a-9b34335982e5@pobox.com \
    --to=daniel.santos@pobox.com \
    --cc=10walls@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=sandra@codesourcery.com \
    --cc=ubizjak@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).