From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109117 invoked by alias); 10 Feb 2017 17:20:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 108540 invoked by uid 89); 10 Feb 2017 17:20:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=anticipate, zones, H*f:sk:e2d2f91, H*MI:sk:e2d2f91 X-HELO: sasl.smtp.pobox.com Received: from pb-smtp1.pobox.com (HELO sasl.smtp.pobox.com) (64.147.108.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Feb 2017 17:20:02 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id D72DC67B13; Fri, 10 Feb 2017 12:19:58 -0500 (EST) Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id CCABD67B12; Fri, 10 Feb 2017 12:19:58 -0500 (EST) Received: from [192.168.1.4] (unknown [76.215.41.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id EAEFF67B11; Fri, 10 Feb 2017 12:19:57 -0500 (EST) Subject: Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues To: JonY <10walls@gmail.com>, Uros Bizjak References: <2fd14fe7-8d06-45ab-fb1e-96c9c8f4c03b@pobox.com> Cc: gcc-patches , Jan Hubicka , Sandra Loosemore From: Daniel Santos Message-ID: <84cec90b-bdcd-2859-ac5a-9b34335982e5@pobox.com> Date: Fri, 10 Feb 2017 17:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 25C322EE-EFB5-11E6-8AEC-FE3F13518317-06139138!pb-smtp1.pobox.com X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00727.txt.bz2 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