From patchwork Mon Nov 25 20:22:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 1200552 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-514552-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=t-online.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="QCxBvPLc"; 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 47MJQ43fbHz9sP6 for ; Tue, 26 Nov 2019 07:23:22 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=bRYAqMU2Q5SgHNkrBxkmV13vbmHOd/81QVWWtOkh85fjEzy0Us 2g3HL5sx1toh82DX77Kjp+K5+5ueJrrEewAdfTwCrkwDRl45hnjPSI3PJlnTFVfE oTg0qI5Kl4e90mnqLYp7GjLuERrcfIqjljrJoVlSClYxia4QKHm25nsjo= 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:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=rZanAi1WDiGLQXqgFu3Y7aHhp/8=; b=QCxBvPLcY9T5RJnD1hD+ +3Fmu/CiEmr33KoWDgmnw39NG/WaZ7BLwi9J53jOvxnsxOk5jSQZpwE2XIF9JbvM Nn1QDLt+H2U5EIlnksi4Boscf9tyGrD5DGIEbMt+1YJIokjrG1tnqBJOEtOkODZn nMcvZHNj++je04hfr2Qx1CI= Received: (qmail 76615 invoked by alias); 25 Nov 2019 20:23:15 -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 76607 invoked by uid 89); 25 Nov 2019 20:23:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPOOFED_FREEMAIL autolearn=ham version=3.3.1 spammy=H*MI:online, combinec, UD:combine.c, combine.c X-HELO: mailout11.t-online.de Received: from mailout11.t-online.de (HELO mailout11.t-online.de) (194.25.134.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Nov 2019 20:23:13 +0000 Received: from fwd08.aul.t-online.de (fwd08.aul.t-online.de [172.20.26.151]) by mailout11.t-online.de (Postfix) with SMTP id A72CD427F36D; Mon, 25 Nov 2019 21:23:10 +0100 (CET) Received: from sweetums.local (Jr0Cq8ZVQhhyoIMBTRyqNKHO1AhuH5rx9yjazxPO3HRI-+yHGFTzut0l3r2JF7-gwU@[84.128.94.135]) by fwd08.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1iZKsu-1jHY1I0; Mon, 25 Nov 2019 21:23:00 +0100 To: GCC Patches Cc: Segher Boessenkool From: Bernd Schmidt Subject: Autoinc vs reload and LRA Openpgp: preference=signencrypt Message-ID: <56a4653b-ca0f-0cb9-f0ec-43027a2da8dd@t-online.de> Date: Mon, 25 Nov 2019 21:22:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 X-IsSubscribed: yes So I was curious what would happen if I turned on LRA for m68k. It turns out my autoinc patches from the cc0 patch set expose a bug in how LRA handles autoincrement. While it copies the logic from reload's inc_for_reload, it appears to be missing the find_reloads_address code to ensure an autoinc address is reloaded entirely if it is part of a jump. LRA can reload just the register inside a POST_INC, which leads to creating an output reload. Hence, a new version of the autoinc changes, below. Since reload is known to work, we allow autoinc in jumps unless targetm.lra_p. One part of the patch is a fix for the earlier combine patch which was already checked in, the other part is a new version of the auto-inc-dec patch. Bootstrapped and tested on the gcc135 machine (powerpc64le-unknown-linux-gnu). OK? Bernd * auto-inc-dec.c (merge_in_block): Allow autoinc in jumps unless LRA is enabled. * combine.c (can_combine_p): Disallow autoinc in jumps unless LRA is disabled. diff --git a/gcc/auto-inc-dec.c b/gcc/auto-inc-dec.c index bdb6efab520..1b224cc9777 100644 --- a/gcc/auto-inc-dec.c +++ b/gcc/auto-inc-dec.c @@ -1441,10 +1441,9 @@ merge_in_block (int max_reg, basic_block bb) continue; } - /* This continue is deliberate. We do not want the uses of the - jump put into reg_next_use because it is not considered safe to - combine a preincrement with a jump. */ - if (JUMP_P (insn)) + /* Reload should handle auto-inc within a jump correctly, while LRA + is known to have issues with autoinc. */ + if (JUMP_P (insn) && targetm.lra_p ()) continue; if (dump_file) diff --git a/gcc/combine.c b/gcc/combine.c index 2e21459f504..3fbd84fcb80 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -2117,12 +2117,16 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn *pred ATTRIBUTE_UNUSED, /* If INSN contains an autoincrement or autodecrement, make sure that register is not used between there and I3, and not already used in - I3 either. Neither must it be used in PRED or SUCC, if they exist. */ + I3 either. Neither must it be used in PRED or SUCC, if they exist. + Also insist that I3 not be a jump if using LRA; if it were one + and the incremented register were spilled, we would lose. + Reload handles this correctly. */ if (AUTO_INC_DEC) for (link = REG_NOTES (insn); link; link = XEXP (link, 1)) if (REG_NOTE_KIND (link) == REG_INC - && (reg_used_between_p (XEXP (link, 0), insn, i3) + && ((JUMP_P (i3) && targetm.lra_p ()) + || reg_used_between_p (XEXP (link, 0), insn, i3) || (pred != NULL_RTX && reg_overlap_mentioned_p (XEXP (link, 0), PATTERN (pred))) || (pred2 != NULL_RTX