From patchwork Fri Jul 12 10:18:47 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 1131261 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-504981-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="WWRuWywR"; dkim-atps=neutral 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 45lTRf5s5Gz9sBF for ; Fri, 12 Jul 2019 20:19:09 +1000 (AEST) 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:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=cNx3qLluwFITT1JZ FsKkNmeyz4zgfnrl7ekDZXaIh6t4PPT4XqhrHZ6vIk0w21geW8Hrpi6AYtzM7LYd azh9j02IRfnsMKfQKg6gMPcuIEYQQ63aJGD8qXFrevC9XAAIopcccgna39WHWubE CNzKbcNVHA3XrtH7yI1J+krrYzE= 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:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=KxsYWK1HoDQrirM6oHn886 Ms9+c=; b=WWRuWywRe6bF6OeToy0l2JgM/bDR7DIo6I5nsjT5lYT3nkPgYOe7gQ Ifcqm5L0asokFFfkU9Dr05bLb4W+pF9B/XVrL/rjkYuk36m/2GDY2Uxcp1QhG63V PRzes49Ak4thC23WnFbXS2jzmoBBEcg1l1P7u4h3Z+yZMFgUvC2nM= Received: (qmail 47099 invoked by alias); 12 Jul 2019 10:19:02 -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 47090 invoked by uid 89); 12 Jul 2019 10:19:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.6 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=famous X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Jul 2019 10:18:51 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 72E8C81398 for ; Fri, 12 Jul 2019 12:18:49 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5AGPF7M61zQ for ; Fri, 12 Jul 2019 12:18:49 +0200 (CEST) Received: from polaris.localnet (unknown [IPv6:2a01:e35:8a16:3850:1a03:73ff:fe45:373a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 4C9058138B for ; Fri, 12 Jul 2019 12:18:49 +0200 (CEST) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: Fix PR rtl-optimization/91136 Date: Fri, 12 Jul 2019 12:18:47 +0200 Message-ID: <1775704.MWxHBReFq7@polaris> MIME-Version: 1.0 This is another installment in the famous series "how can this have worked for so long?". The delayed branches scheduling pass, aka dbr in reorg.c, uses its own dataflow algorithm implemented in resource.c to do liveness analysis after starting from seeds obtained from DF. It's a forward scan starting from the DF_LR_IN set of a well-chosen basic block and then updating this set as the instructions are being processed. The problem is that, when this basic block has incoming EH edges, there are implicitly live registers on entry by virtue of EH_RETURN_DATA_REGNO. Now DF encodes them specially: For blocks that are at the destination of eh edges, the artificial uses and defs occur at the beginning. The defs relate to the registers specified in EH_RETURN_DATA_REGNO and the uses relate to the registers specified in EH_USES. Logically these defs and uses should really occur along the eh edge, but there is no convenient way to do this. Artificial defs that occur at the beginning of the block have the DF_REF_AT_TOP flag set. This means in particular that the artificial defs are not in the DF_LR_IN set, which means that resource.c doesn't see them at all. Another pass has exactly the same issue (register renaming) but has been adjusted, so the attached fix just mimics what init_rename_info in regrename.c does. Bootstrapped/regtested on SPARC/Solaris, applied on all active branches. 2019-07-12 Eric Botcazou PR rtl-optimization/91136 * df-core.c (ACCESSING REFS): Fix typos in comment. * resource.c (mark_target_live_reg): Add artificial defs that occur at the beginning of the block to the initial set of live registers. Index: df-core.c =================================================================== --- df-core.c (revision 273294) +++ df-core.c (working copy) @@ -298,12 +298,12 @@ There are 4 ways to obtain access to ref Artificial defs and uses occur both at the beginning and ends of blocks. - For blocks that area at the destination of eh edges, the + For blocks that are at the destination of eh edges, the artificial uses and defs occur at the beginning. The defs relate to the registers specified in EH_RETURN_DATA_REGNO and the uses - relate to the registers specified in ED_USES. Logically these + relate to the registers specified in EH_USES. Logically these defs and uses should really occur along the eh edge, but there is - no convenient way to do this. Artificial edges that occur at the + no convenient way to do this. Artificial defs that occur at the beginning of the block have the DF_REF_AT_TOP flag set. Artificial uses occur at the end of all blocks. These arise from Index: resource.c =================================================================== --- resource.c (revision 273294) +++ resource.c (working copy) @@ -987,9 +987,13 @@ mark_target_live_regs (rtx_insn *insns, { regset regs_live = DF_LR_IN (BASIC_BLOCK_FOR_FN (cfun, b)); rtx_insn *start_insn, *stop_insn; + df_ref def; /* Compute hard regs live at start of block. */ REG_SET_TO_HARD_REG_SET (current_live_regs, regs_live); + FOR_EACH_ARTIFICIAL_DEF (def, b) + if (DF_REF_FLAGS (def) & DF_REF_AT_TOP) + SET_HARD_REG_BIT (current_live_regs, DF_REF_REGNO (def)); /* Get starting and ending insn, handling the case where each might be a SEQUENCE. */