From patchwork Sun Mar 31 16:53: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: 87868 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 362DD3858432 for ; Sun, 31 Mar 2024 16:54:21 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id D66893858D1E for ; Sun, 31 Mar 2024 16:53:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D66893858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D66893858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711904035; cv=none; b=Z86Il4owL713t4eZhvdebrGSZpoJJkSB/DCJsDMzht0mMxXV+kObjyIU4cAOw+UI759WWhVvhPIDabWxfBmye5BWgQtrYjTRtb5Rk71wWOisfYCp1B+cli3gV18AZMg6Rb5pAbZDlqeZrhH+q+x3MNcPh6HhyZTLn+ukR46oQO8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711904035; c=relaxed/simple; bh=KQBOdYsRpdQnaWD0s5ZbG3zovKivj/QuIRBql0eJq8M=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=m3qwYku6b0DsfCmR5yySNSlmt/z3s6GjEH26cZhPKdqo3QGbtvjABBu4hW3e4UMEc7XoEn0RPTvweYRlRZVoQl50KPAX8SB5Ps0qgz8VXBD2fluOyE/nqe9AIJSiF6EYzSUg6fsaRnUj7gJgA9pCfSUPUbSGe/eH7H4s2axR48Y= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1e0f3052145so32433165ad.2 for ; Sun, 31 Mar 2024 09:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1711904032; x=1712508832; darn=gcc.gnu.org; h=subject:from:cc:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=VbuCBtFrMUxVLe6MY4pUG+Dd8eJu2tSG/MULl0etdOU=; b=ar2LemAZbC6EspyNH8xXxBNnx2tAv5nDqY3hkIoMeyCkmFAdumEm1n8+nL+6qtGW9Y J9W89YLt+W1Mvv4K2D1+gpx+Xsc0ttmXLzCnNY/WOtYO0b80SFO7bHuwG+DaXKeCzcu+ qkK+WADqxjgM1aNu2VGUosTFM8iSoZjHtTxkdxMeEmyemK4dKcL6/5zxPKEpoI4Amyz8 am95338LrMx7mf6bO94N4CqWgz4/jDB2VNbkaeFz1P6NO4FLqsTMl9fwXLipFLBfjuFd 7cRymqQk68WVhAqxbcpH83CeaEwYNABr0SEGAHyG4aPLjN/mBAwzMa1yD1F8PFq1KXab QTVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711904032; x=1712508832; h=subject:from:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VbuCBtFrMUxVLe6MY4pUG+Dd8eJu2tSG/MULl0etdOU=; b=YRIbs2Cc8/t/bbFlKraXUVOI1XV0ppOhhu9BgiWGG5uDJKWbqQ5a9WxIcGtQbLSjf0 xmzdcxk5qzubAtPIxR9WW0Cjk2YhrQor2yQji/k2DeQMf8XcxoTVcG7QKBP3hpngv4Is s028EEMFvVFswUDuL4DyJ1VUweCSFGjbKLeddgqH7O1351KqdwhJV8LOl+4My4WcopHv r+96QxVITcT+FeKm2hcWuOL5C+5IUpB3EXfoooMj2Ejb1+dv28L9cAX4OJHs6B17yTb7 YG7cYS+k4uD/xc4U8D08IC5FGcWPsivDiSsz5w4mN9JEaolULsJYsLaRVptqh6npSo/5 mJYw== X-Gm-Message-State: AOJu0YxlPTZSsyJUcMGBKRO6eelcpd8fmq72EpW8FTarAMIeNkPwe8L0 vqapBs3VHtKshLo49kxVX2Nsho5Hd6OGns1qa4O4mkc7xC3GWKSdmVQghS8tHu+JPSCPGalYyZZ H X-Google-Smtp-Source: AGHT+IGbOIDdrMH6JNNMA7sSMXn8tU7cqmLLc34NVJ8+zSX/sVsH9ZwJP7JhS8dhbJduxacwgkLaVA== X-Received: by 2002:a17:902:8211:b0:1dc:ad9c:4c9d with SMTP id x17-20020a170902821100b001dcad9c4c9dmr7011987pln.31.1711904032423; Sun, 31 Mar 2024 09:53:52 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id w22-20020a1709026f1600b001e0b5f9fb02sm7206433plk.26.2024.03.31.09.53.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 Mar 2024 09:53:52 -0700 (PDT) Message-ID: <1df2a508-1116-4d5f-b77a-91649cecc770@ventanamicro.com> Date: Sun, 31 Mar 2024 10:53:46 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US To: "gcc-patches@gcc.gnu.org" Cc: Chen Jiawei From: Jeff Law Subject: [committed] RISC-V: Add missing insn types to XiangShan Nanhu scheduler model X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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+patchwork=sourceware.org@gcc.gnu.org The test for the recently added XiangShan Nanhu microarchitecture is failing because the scheduler description does not have entries for certain insn types. I'm adding branch, jalr, ret and sfb_alu to the scheduler description, that's enough to get the trivial test to pass. However, I strongly suspect running any significant code through the compiler when scheduling for this microarchitecture will trigger faults. Basically we have checking now that will fault if we have an insn in the IL without an associated type or if we have an insn in the IL that does not map to an insn reservation in the scheduler model. We were tripping the latter assertion for one of those branch types. My suspicion is many insn types aren't handled by that DFA. The branch insns were pretty obvious and easy to fix. But someone with more experience with the uarch needs to do an audit to ensure that all insn types map to an insn reservation. Pushing this to the trunk. Jeff commit 08eaafadd5beaa56beb2d1fceca9f97eeb0219ba Author: Jeff Law Date: Sun Mar 31 10:51:17 2024 -0600 [committed] RISC-V: Add missing insn types to XiangShan Nanhu scheduler model The test for the recently added XiangShan Nanhu microarchitecture is failing because the scheduler description does not have entries for certain insn types. I'm adding branch, jalr, ret and sfb_alu to the scheduler description, that's enough to get the trivial test to pass. However, I strongly suspect running any significant code through the compiler when scheduling for this microarchitecture will trigger faults. Basically we have checking now that will fault if we have an insn in the IL without an associated type or if we have an insn in the IL that does not map to an insn reservation in the scheduler model. We were tripping the latter assertion for one of those branch types. My suspicion is many insn types aren't handled by that DFA. The branch insns were pretty obvious and easy to fix. But someone with more experience with the uarch needs to do an audit to ensure that all insn types map to an insn reservation. gcc/ * config/riscv/xiangshan.md (xiangshan_jump): Add branch, jalr, ret and sfb_alu. diff --git a/gcc/config/riscv/xiangshan.md b/gcc/config/riscv/xiangshan.md index 381c3ce1428..76539d332b8 100644 --- a/gcc/config/riscv/xiangshan.md +++ b/gcc/config/riscv/xiangshan.md @@ -70,7 +70,7 @@ (define_insn_reservation "xiangshan_fpstore" 1 (define_insn_reservation "xiangshan_jump" 1 (and (eq_attr "tune" "xiangshan") - (eq_attr "type" "jump,call,auipc,unknown")) + (eq_attr "type" "jump,call,auipc,unknown,branch,jalr,ret,sfb_alu")) "xs_jmp_rs") (define_insn_reservation "xiangshan_i2f" 3