From patchwork Wed Jul 3 18:46:46 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1956411 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=jPyvLqp2; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4WDpfv2Gjxz1xqh for ; Thu, 4 Jul 2024 04:47:17 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 86875386100E for ; Wed, 3 Jul 2024 18:47:15 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 56B2B384A80B for ; Wed, 3 Jul 2024 18:46:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 56B2B384A80B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 56B2B384A80B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::335 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720032412; cv=none; b=Z++Twf57hrSsFnlMJnfH2Fl5OMiz1OiHNzc1GRqR5gESRxmUzjAYZzvT3r0gAoQ6qMrKMzCWvaZt2eC7XAehsbhq7StG9X2+9piLrkbOvHj5GpVL959EhVJlBOtaXfhQLPmsECN63QDoELOcyNqNFxM2ShhjEQYOC04E6TSbPlU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720032412; c=relaxed/simple; bh=kahTYaTov7yMtySlmJ1aPb5ivFEDChSGzWdeUq7u1Mc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=Dndpua/Hu5map6y6cgMvafGvawNsOnOGDnwtLvHb5QhsJ8l5jOSc6kmAEIO+LYPIFcq0ck+wjQBWJHwO7sQ4VzXVoj8d9uUONPHUOyP5ErYCvLMH8qzA+Vjg+ifBoT+JCojFUu/gpHnmEuiTM5rm/MYQ2La9Wz8fssQhKSEnIRw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-701eea2095eso3411727a34.2 for ; Wed, 03 Jul 2024 11:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720032408; x=1720637208; darn=gcc.gnu.org; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=pYjQkkKHeU8JOmQ4zYsOESuYVQN6Hfd9ncDSorX+fe8=; b=jPyvLqp2gBRwSTnkRvkWNKbzmS6pGR0fhBbOLXBArYuU4ak0yszS07rKktTHTfZwCM RW26r4ArQl/t75ausSJiNp7w+k5V+ZlBAENDzylChBguGhfFZstg1BO55N8hzl7elI0c pdwCotkRslNrxNMjbskiDDNroaW7DlabrlLTa2v3GwP1ceeBrmRnfgmEXtzCM0268qTa 3pwar0vmD2I/dyk7qHQnwACpMx6MBrfXPuy4YafCOxcZO0R9G+zjA+GlAylS8wo7IyY7 vYF7J7kcDFuZHQdusT0jREVQRlsYtg9BNdStwTJ3ceVF66JqrN69BjEb8ItdvE9ujzKr echw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720032408; x=1720637208; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pYjQkkKHeU8JOmQ4zYsOESuYVQN6Hfd9ncDSorX+fe8=; b=VlgcFaHuQmGCZ0lzCWCCmK81zNU06kY8UQxNOD3r4nO556SyKmC/qFa+n2Shmisrwp WIOrI04qdOd02lX+THGM5LQxKVqrtUNkZiTDSRl9ZUYa74Xn4EoHyFKCdRZfKrPc7hHP ALvuBHMGXlcLGagb4E72lQrf7ggxCxN4G5oI7EqZg+EaqhoKnrwJUPtuiSVjIAMQDbOh tk82S7gIfQYLYzGIt66b2tqV6E4bamLhkQGFJo49jMdK63eCNn/rpFaz3qkUFOHjq4b6 ucft+aEGXgVV7BFRlaviY4yMp3VQgJ2TLsRxcHf4jJejs4g+Za18W2LFdnWu962/cJ5M ZPWA== X-Gm-Message-State: AOJu0YzGfh7zu+UkaTNbik4dNfWACowkRjUqt/NrydGH6sFl06AN57pk mARjMFkxJ5kHp41gcBZNZIr0T4qjMdPSj0tdmxDT6dAW8fPM/rkiIKRnzA== X-Google-Smtp-Source: AGHT+IHcgBOJO+MLFiDzAwMn+9x+AvTHdgRze1ONd/YxMMwG+WRnKYU5Lk6VcoIA6EMyos0P6ZMWXQ== X-Received: by 2002:a9d:4f18:0:b0:6f9:5dbf:d3af with SMTP id 46e09a7af769-7020764b36cmr15507662a34.22.1720032408138; Wed, 03 Jul 2024 11:46:48 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-701f7b209f5sm2100453a34.52.2024.07.03.11.46.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jul 2024 11:46:47 -0700 (PDT) Message-ID: <60fc2780-24f1-4567-a91f-7b227f299621@gmail.com> Date: Wed, 3 Jul 2024 12:46:46 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US To: "gcc-patches@gcc.gnu.org" From: Jeff Law Subject: [committed] Fix previously latent bug in reorg affecting cris port X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org The late-combine patch has triggered a previously latent bug in reorg. Basically we have a sequence like this in the middle of reorg before we start relaxing delay slots (cris-elf, gcc.dg/torture/pr98289.c) > (insn 67 49 18 (sequence [ > (jump_insn 50 49 52 (set (pc) > (if_then_else (ne (reg:CC 19 ccr) > (const_int 0 [0])) > (label_ref:SI 30) > (pc))) "j.c":10:6 discrim 1 282 {*bnecc} > (expr_list:REG_DEAD (reg:CC 19 ccr) > (int_list:REG_BR_PROB 7 (nil))) > -> 30) > (insn/f 52 50 18 (set (mem:SI (reg/f:SI 14 sp) [1 S4 A8]) > (reg:SI 16 srp)) 37 {*mov_tomemsi} > (nil)) > ]) "j.c":10:6 discrim 1 -1 > (nil)) > > (note 18 67 54 [bb 3] NOTE_INSN_BASIC_BLOCK) > > (note 54 18 55 NOTE_INSN_EPILOGUE_BEG) > > (jump_insn 55 54 56 (return) "j.c":14:1 228 {*return_expanded} > (nil) > -> return) > > (barrier 56 55 43) > > (note 43 56 65 [bb 4] NOTE_INSN_BASIC_BLOCK) > > (note 65 43 30 NOTE_INSN_SWITCH_TEXT_SECTIONS) > > (code_label 30 65 8 5 6 (nil) [1 uses]) > > (note 8 30 61 [bb 5] NOTE_INSN_BASIC_BLOCK) So at a high level the things to note are that insn 50 conditionally jumps around insn 55. Second there's a SWITCH_TEXT_SECTIONS note between insn 50 and the target label for insn 50 (code_label 30). reorg sees the conditional jump around the unconditional jump/return and will invert the jump and retarget the original jump to an appropriate location. In this case generating: > (insn 67 49 18 (sequence [ > (jump_insn 50 49 52 (set (pc) > (if_then_else (eq (reg:CC 19 ccr) > (const_int 0 [0])) > (label_ref:SI 68) > (pc))) "j.c":10:6 discrim 1 281 {*beqcc} > (expr_list:REG_DEAD (reg:CC 19 ccr) > (int_list:REG_BR_PROB 1073741831 (nil))) > -> 68) > (insn/s/f 52 50 18 (set (mem:SI (reg/f:SI 14 sp) [1 S4 A8]) > (reg:SI 16 srp)) 37 {*mov_tomemsi} > (nil)) > ]) "j.c":10:6 discrim 1 -1 > (nil)) > > (note 18 67 54 [bb 3] NOTE_INSN_BASIC_BLOCK) > > (note 54 18 43 NOTE_INSN_EPILOGUE_BEG) > > (note 43 54 65 [bb 4] NOTE_INSN_BASIC_BLOCK) > > (note 65 43 8 NOTE_INSN_SWITCH_TEXT_SECTIONS) > > (note 8 65 61 [bb 5] NOTE_INSN_BASIC_BLOCK) [ ... ] Where the new target of the jump is a return statement later in the IL. Note that we now have a SWITCH_TEXT_SECTIONS note that is not immediately preceded by a BARRIER. That triggers an assertion in the dwarf2 code. Removal of the BARRIER is inherent in this optimization. The fix is simple, we avoid this optimization when there's a SWITCH_TEXT_SECTIONS note between the conditional jump insn and its target. Thankfully we already have a routine to test for this in reorg, so we just need to call it appropriately. The other approach would be to drop the note which I considered and discarded. We don't have great coverage for delay slot targets. I've tested arc, cris, fr30, frv, h8, iq2000, microblaze, or1k, sh3 visium in my tester as crosses without new regressions, fixing one regression along the way. Bootstrap & regression testing on sh4 and hppa will take considerably longer. Pushing to the trunk momentarily. Jeff gcc/ * reorg.cc (relax_delay_slots): Do not optimize a conditional jump around an unconditional jump/return in the presence of a text section switch. diff --git a/gcc/reorg.cc b/gcc/reorg.cc index 99228a22c69..633099ca765 100644 --- a/gcc/reorg.cc +++ b/gcc/reorg.cc @@ -3409,7 +3409,8 @@ relax_delay_slots (rtx_insn *first) && next && simplejump_or_return_p (next) && (next_active_insn (as_a (target_label)) == next_active_insn (next)) - && no_labels_between_p (insn, next)) + && no_labels_between_p (insn, next) + && !switch_text_sections_between_p (insn, next_active_insn (next))) { rtx label = JUMP_LABEL (next); rtx old_label = JUMP_LABEL (delay_jump_insn);