From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id B184E3858D20 for ; Fri, 11 Aug 2023 03:19:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B184E3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-26929bf95b6so936836a91.3 for ; Thu, 10 Aug 2023 20:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691723944; x=1692328744; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=IXnOYO3G3NVaioOmcE9otYhNyNqVHE3aeF3cKX1nbug=; b=e+TBDtTO92j1yDfneeFrDS9CK8k3CzEgmQTE8zsyWruK5BF+yv/LES3aIf2ODQY9AR pr+/KpD1nmKHU9PUtl2z/CROqJj3c40rme3piwQkeX9igP/XsOb2XfNSfUPgjLSGPXah q5WGDJAz/CcxGogeGhFeh6LHADG7E6OwTlapOqbKPegl0doQw7qYa+I6/NHmpsXlIjI/ c0Fmy01IZQGOW6yXMMGPRoHEeQZZSsLw0TLIPhfMZGpNr8iCA/mptw33FsJ8zCxire3A PLClIK8rnTsQ4FCj2FjEUc/44NCzARNUsp2WeUdXD/hA4yEtdPgapAbig61AlT3WetOg D+8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691723944; x=1692328744; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IXnOYO3G3NVaioOmcE9otYhNyNqVHE3aeF3cKX1nbug=; b=hh0vqlVXvapotA/CvLSm0DfchzYmZ9bVxKrr2MVacp4/KcwdSHz0YqsEms/W0DJvVu c6r3blkObcr9/UO32Vv9WUN9oqjzeISDRcZIruE0nLelMRIcN7pmJ4QnQJWJTimamhD1 djB9k4xGxIQUgFaq4zA9+TZZpkZLYGX+gUmNCIJ/ZL8IRWqXPKQs2HjDfE+QrVn4II5x 2h//SubgnWmvqBiTBo9tUtEtSEJ4RaP+nwvpJ99MK26n804M5y+YfFGu+wj7QMha57KQ QMcALye+a/PxrwlGQyjoPjG2CGPai+bOV2i8PdrZzhNoQ4iMx2XfuH+EQlcOmwYDLmaE 9LWQ== X-Gm-Message-State: AOJu0YynqzgexZ+5luVx9vPKLQY/yF6bBhTtqBJdoFi/B+OlZ8TpH3eB d3tWMxiXjBZeKFQS0cIVlqQ= X-Google-Smtp-Source: AGHT+IGZqEBkcRHKQgO3x/kuLx7eH3naaI9oOXDD3y9gu5Z/fDJCxtmum9Q8Tfxs6cg1ZRHcWixcew== X-Received: by 2002:a17:90a:64c2:b0:268:414c:ff3 with SMTP id i2-20020a17090a64c200b00268414c0ff3mr336990pjm.23.1691723944413; Thu, 10 Aug 2023 20:19:04 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id l9-20020a17090a070900b00267b38f5e13sm2400488pjl.2.2023.08.10.20.19.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Aug 2023 20:19:03 -0700 (PDT) Message-ID: <11fc8df2-4352-4462-6228-925d85490088@gmail.com> Date: Thu, 10 Aug 2023 21:19:02 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] RISC-V: Handle no_insn in TARGET_SCHED_VARIABLE_ISSUE. Content-Language: en-US To: Palmer Dabbelt , gcc-patches@gcc.gnu.org Cc: richard.sandiford@arm.com, Kito Cheng , christoph.muellner@vrull.eu, jinma.contrib@gmail.com References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 List-Id: On 8/10/23 20:30, Palmer Dabbelt wrote: > > Sorry for being lost here, but I'm not sure where TYPE_UNKNOWN comes > from.  There's not a whole lot of instances in the code, and they all > seem to be doing something very special.  Is it just something we didn't > do a '(set_attr "type" ...)' on? Yup. TYPE_UNKNOWN means we don't have a type associated with the insn. As I've mentioned before this isn't a major problem if there's one or two here and there. But if most are TYPE_UNKNOWN, the the scheduler is going to do highly unnatural things. > > In that case it seems reasonable to have a dev-mode early failure: we've > got some odd types now (like just the broad "bitmanip" one), but those > can be split later.  At least having some classification seems like the > way to go, it's just an internal interface so we can make it better later. > > That said, it also smells like this is something that should be more > generic than backend code? No, it's really a target issue. And what I was suggesting is that we get to the point where we can enable the currently #if 0'd assert so that if we introduce insns without an associated type, we get a nice early warning. I wasn't up for tackling that this week ;-) > >>> > The other thing if this code probably wants to handle GHOST type > >>> instructions.  While GHOST is used for instructions which generate no >>> > code, it might seem they should return "more" as those INSNs take >>> no > resources.  But GHOST is actually used for things like the >>> blockage insn > which should end a cycle from an issue standpoint. >>> So the right > handling of a GHOST is something like this: >>> > > if (type == TYPE_GHOST) >>> >    return 0; > > Lost again, here, there's almost no references to TYPE_GHOST (aside from > a MIPS-ism that looks to have ended up in Loongarch). Search for "ghost" in riscv.md ;-) Jeff