From patchwork Mon May 15 20:39:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 762714 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wRXWR69T7z9s8D for ; Tue, 16 May 2017 06:39:47 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="blwDCd31"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:content-id:content-transfer-encoding:mime-version; q=dns; s=default; b=wV///z0ZQGCIBBWUYdGidaj40JRvaoYUzLgQ05yhGqh 3aCjR2Hkvf4GtGB3iM8o2YqDEo3T3I2sa9W0IRDv4/3bJK2T3bUQFPmyoygk1Xhk KNp60C+tMzJgSN97Sle15HRhixLbxWxykc7LIh4NBZG1O+ZSG/OOBrB677QxYeQQ = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:content-id:content-transfer-encoding:mime-version; s=default; bh=u2EtndoF9SMf3vWph6SEoxT4dMI=; b=blwDCd31XFD+0MAmV jPjhDjZMVpO+gJU4WMv6Mxh+4U3Ibpm9iFgV6NybIByYxasqhZHladEbSEiQjmeF PuwoBU8IrweI9+GtSGRdPXlV/Jm5qoy0gj/bMmuESR0Tq36ODlgdnU/hkm2+ePIm 6UU2/V0EZzw/oEqp8JagSduvPI= Received: (qmail 102967 invoked by alias); 15 May 2017 20:39:32 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 102947 invoked by uid 89); 15 May 2017 20:39:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, MIME_BASE64_BLANKS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3276, 5958 X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-oln040092070018.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.92.70.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 May 2017 20:39:29 +0000 Received: from AM5EUR03FT057.eop-EUR03.prod.protection.outlook.com (10.152.16.55) by AM5EUR03HT135.eop-EUR03.prod.protection.outlook.com (10.152.17.176) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1075.5; Mon, 15 May 2017 20:39:29 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.16.58) by AM5EUR03FT057.mail.protection.outlook.com (10.152.17.44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Mon, 15 May 2017 20:39:29 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([fe80::55fc:f172:98b5:d2bc]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([fe80::55fc:f172:98b5:d2bc%19]) with mapi id 15.01.1101.011; Mon, 15 May 2017 20:39:29 +0000 From: Bernd Edlinger To: Daniel Santos CC: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] [i386] Recompute the frame layout less often Date: Mon, 15 May 2017 20:39:29 +0000 Message-ID: References: <9aa7427e-6cfc-b603-2ec4-1f0e02ae294d@pobox.com> <20c96fa0-328b-af1a-c558-dab6652c482e@pobox.com> In-Reply-To: <20c96fa0-328b-af1a-c558-dab6652c482e@pobox.com> authentication-results: pobox.com; dkim=none (message not signed) header.d=none; pobox.com; dmarc=none action=none header.from=hotmail.de; x-incomingtopheadermarker: OriginalChecksum:553D0C0AC29F4D4CA8B9D94960ABAB38ABE5F10847A28EACED7DE359064AB0F0; UpperCasedChecksum:CB5432CE7483982338B87DFA2A2C5D431E739955C67A2F15887DA7C5EE87E884; SizeAsReceived:8469; Count:43 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5EUR03HT135; 5:2qI50pFT7w3MRkm3rVaKbl8GlalRsez3NVB1WxcIsflb6s7ObYPlUNGKF9fYhTx78uR49NitzU5J83ozpWoIZscfEjgsmcKMlS4J6BHfcuZzIsHwnsWe7Qeiog6OEq4y454FHlYaH7SQ8KSk6R5FYw==; 24:/xMyReb3ZqQftM08mc6Dgr+qrcjXcg1sgDYKUMjbEz+3W9eB3eZ5E2+kFDh6gFRX40uwrUbsqBRkH+fNYwUeFrwiUSm3+XygXyf3aO3ySUo=; 7:h8ZBB4g3znPQ3YBUX5Z9LPYDjjigjKpWdkqsLhE3K96YGx9HMa/NYl/vyb+55Ykx4dpXLAp987mlB4x1kzyp9p5d4NGr2RP9YmmTDPY2M4jV1REQGXmO8cUZbVfhuH3Ezrp8IGGhQrg2bKrvZxcqJ01di6BkNzDZXHMFQBXcmk2Pv7HSczBxYiyLdk/0E7JiEcFrgcbZfOl1U65FsmF94Lhc05T1xl+wcR3cNaULbZIQHhRpgaEZpwx1cUYvW7Ox3plhbZLULT9D4LvJpVFqFyIsrgp47jFtt67ZBaYlLv2s1dRn3m59QOcsCmrWnZeB x-incomingheadercount: 43 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR03HT135; H:AM4PR0701MB2162.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 88d4aac7-9d26-4b63-0d1c-08d49bd27b80 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:AM5EUR03HT135; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:AM5EUR03HT135; BCL:0; PCL:0; RULEID:; SRVR:AM5EUR03HT135; x-forefront-prvs: 0308EE423E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 20:39:29.4899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT135 On 05/15/17 03:39, Daniel Santos wrote: > On 05/14/2017 11:31 AM, Bernd Edlinger wrote: >> Hi Daniel, >> >> there is one thing I don't understand in your patch: >> That is, it introduces a static value: >> >> /* Registers who's save & restore will be managed by stubs called from >> pro/epilogue. */ >> static HARD_REG_SET GTY(()) stub_managed_regs; >> >> This seems to be set as a side effect of ix86_compute_frame_layout, >> and depends on the register usage of the current function. >> But values that depend on the current function need usually be >> attached to cfun->machine, because the passes can run in parallel >> unless I am completely mistaken, and the stub_managed_regs may >> therefore be computed from a different function. >> >> >> Bernd. > > I should add that if you want to run faster tests just on the ms to sysv > abi code, you can use make RUNTESTFLAGS="ms-sysv.exp" check and then if > that succeeds run the full testsuite. > > Daniel Unfortunately I encounter a serious problem when my patch is used ontop of your patch, Yes, the test suite ran without error, but then I tried to trigger the warning and that tripped an ICE. The reason is that cfun->machine->call_ms2sysv can be set to true *after* reload_completed, which can be seen using the following patch: That assertion is triggered in this test case: cat test.c int test() { __builtin_printf("test\n"); return 0; } gcc -mabi=ms -mcall-ms2sysv-xlogues -fsplit-stack -c test.c test.c: In function 'test': test.c:5:1: internal compiler error: in ix86_expand_call, at config/i386/i386.c:29324 } ^ 0x13390a4 ix86_expand_call(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, bool) ../../gcc-trunk/gcc/config/i386/i386.c:29324 0x1317494 ix86_expand_split_stack_prologue() ../../gcc-trunk/gcc/config/i386/i386.c:15920 0x162ba21 gen_split_stack_prologue() ../../gcc-trunk/gcc/config/i386/i386.md:12556 0x12f3f30 target_gen_split_stack_prologue ../../gcc-trunk/gcc/config/i386/i386.md:12325 0xb237b3 make_split_prologue_seq ../../gcc-trunk/gcc/function.c:5822 0xb23a08 thread_prologue_and_epilogue_insns() ../../gcc-trunk/gcc/function.c:5958 0xb24840 rest_of_handle_thread_prologue_and_epilogue ../../gcc-trunk/gcc/function.c:6428 0xb248c0 execute ../../gcc-trunk/gcc/function.c:6470 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. so, in ix86_expand_split_stack_prologue we first call: ix86_finalize_stack_realign_flags (); ix86_compute_frame_layout (&frame); and later: call_insn = ix86_expand_call (NULL_RTX, gen_rtx_MEM (QImode, fn), GEN_INT (UNITS_PER_WORD), constm1_rtx, pop, false); which changes a flag with a huge impact on the frame layout, but there is no absolutely no way how the frame layout can change once it is finalized. Any Thoughts? Bernd. Index: i386.c =================================================================== --- i386.c (revision 248031) +++ i386.c (working copy) @@ -29320,7 +29320,10 @@ /* Set here, but it may get cleared later. */ if (TARGET_CALL_MS2SYSV_XLOGUES) + { + gcc_assert(!reload_completed); cfun->machine->call_ms2sysv = true; + } } if (vec_len > 1)