From patchwork Thu Mar 7 08:22:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 86915 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 44AA53857BAE for ; Thu, 7 Mar 2024 08:23:25 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 2DAB23858D39 for ; Thu, 7 Mar 2024 08:22:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DAB23858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2DAB23858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709799767; cv=none; b=YINqfgndVNvhksFthuJ/KeGVQ2+NYqgQdQMhZEU+giqmTtgDS+lqc4Bd9hNi1CmyYexVyjs9sRSMMluC9BLk+rjLwiOV7KBuky6qwSTTFEpo8/iAz9HCudR9usLre5GkBHFxTbH4+rt47kd72euptwQfyqfvmHSzq4MBML/5o5A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709799767; c=relaxed/simple; bh=Liff6iGI0y3teU3UO24uCeRtQZoAaJ/jZkYHHqSbujo=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=ODG6LLOqmFn/roZhqOVpcv9BPOS97JkC/Yu/CClUewZMzjGf3ZinAvf7J0HXKUJlcDEMjS5RJVWuxjWs8slq6DssdKK5aG6DRLynT6epSUXp5mRaFICysGWI9ibX9LDkoCpTcgMNQ4epVjoD5d3qzsexjzIUI2oK1KWSccAlr7g= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709799762; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=ce65Oau2RNd6ueOxc4NjdOZnymdW3b/MBvaoek18yLs=; b=EmrNlja8MvX/s5crTAp5K9pDCM1s80lt1Zfkeb4j1fe9qp35oLwHvBtQu9G8+aqXVw96q9 NKBBJ8Y+4aP2kh+EBu+wHKlRYVSkMcGqzdlaqyjMJr5OvYepjijltGlo9atuOJA3Ud//n4 rGPmDPXmyJxRTTOEK3YfQir2g+qzTmY= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-343-cnaEkXn_NNi_e9mfVSQQDQ-1; Thu, 07 Mar 2024 03:22:38 -0500 X-MC-Unique: cnaEkXn_NNi_e9mfVSQQDQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9EC273800539; Thu, 7 Mar 2024 08:22:38 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.226.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 642D5492BDC; Thu, 7 Mar 2024 08:22:38 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4278MaWg2806182 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 7 Mar 2024 09:22:37 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4278MaJY2806181; Thu, 7 Mar 2024 09:22:36 +0100 Date: Thu, 7 Mar 2024 09:22:36 +0100 From: Jakub Jelinek To: Jan Hubicka , Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] bb-reorder: Fix -freorder-blocks-and-partition ICEs on aarch64 with asm goto [PR110079] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: , Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Hi! The following testcase ICEs, because fix_crossing_unconditional_branches thinks that asm goto is an unconditional jump and removes it, replacing it with unconditional jump to one of the labels. This doesn't happen on x86 because the function in question isn't invoked there at all: /* If the architecture does not have unconditional branches that can span all of memory, convert crossing unconditional branches into indirect jumps. Since adding an indirect jump also adds a new register usage, update the register usage information as well. */ if (!HAS_LONG_UNCOND_BRANCH) fix_crossing_unconditional_branches (); I think for the asm goto case, for the non-fallthru edge if any we should handle it like any other fallthru (and fix_crossing_unconditional_branches doesn't really deal with those, it only looks at explicit branches at the end of bbs and we are in cfglayout mode at that point) and for the labels we just pass the labels as immediates to the assembly and it is up to the user to figure out how to store them/branch to them or whatever they want to do. So, the following patch fixes this by not treating asm goto as a simple unconditional jump. I really think that on the !HAS_LONG_UNCOND_BRANCH targets we have a bug somewhere else, where outofcfglayout or whatever should actually create those indirect jumps on the crossing edges instead of adding normal unconditional jumps, I see e.g. in __attribute__((cold)) int bar (char *); __attribute__((hot)) int baz (char *); void qux (int x) { if (__builtin_expect (!x, 1)) goto l1; bar (""); goto l1; l1: baz (""); } void corge (int x) { if (__builtin_expect (!x, 0)) goto l1; baz (""); l2: return; l1: bar (""); goto l2; } with -O2 -freorder-blocks-and-partition on aarch64 before/after this patch just b .L? jumps which I believe are +-32MB, so if .text is larger than 32MB, it could fail to link, but this patch doesn't address that. Bootstrapped/regtested on x86_64-linux, i686-linux and aarch64-linux, ok for trunk? 2024-03-07 Jakub Jelinek PR rtl-optimization/110079 * bb-reorder.cc (fix_crossing_unconditional_branches): Don't adjust asm goto. * gcc.dg/pr110079.c: New test. Jakub --- gcc/bb-reorder.cc.jj 2024-01-03 11:51:32.000000000 +0100 +++ gcc/bb-reorder.cc 2024-03-06 18:34:29.468016144 +0100 @@ -2266,7 +2266,8 @@ fix_crossing_unconditional_branches (voi /* Make sure the jump is not already an indirect or table jump. */ if (!computed_jump_p (last_insn) - && !tablejump_p (last_insn, NULL, NULL)) + && !tablejump_p (last_insn, NULL, NULL) + && !asm_noperands (PATTERN (last_insn))) { /* We have found a "crossing" unconditional branch. Now we must convert it to an indirect jump. First create --- gcc/testsuite/gcc.dg/pr110079.c.jj 2024-03-06 18:42:47.175250069 +0100 +++ gcc/testsuite/gcc.dg/pr110079.c 2024-03-06 18:44:47.008620726 +0100 @@ -0,0 +1,43 @@ +/* PR rtl-optimization/110079 */ +/* { dg-do compile { target lra } } */ +/* { dg-options "-O2" } */ +/* { dg-additional-options "-freorder-blocks-and-partition" { target freorder } } */ + +int a; +__attribute__((cold)) int bar (char *); +__attribute__((hot)) int baz (char *); + +void +foo (void) +{ +l1: + while (a) + ; + bar (""); + asm goto ("" : : : : l2); + asm (""); +l2: + goto l1; +} + +void +qux (void) +{ + asm goto ("" : : : : l1); + bar (""); + goto l1; +l1: + baz (""); +} + +void +corge (void) +{ + asm goto ("" : : : : l1); + baz (""); +l2: + return; +l1: + bar (""); + goto l2; +}