This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]