From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id C11D93858D28 for ; Fri, 11 Aug 2023 13:29:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C11D93858D28 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-pg1-x52c.google.com with SMTP id 41be03b00d2f7-563f8e8a53dso1291538a12.3 for ; Fri, 11 Aug 2023 06:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691760578; x=1692365378; 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=5paRZUGqJ3D1Mj/KW5eb90ngrh15fKmpdB5pZI/clCU=; b=m2gc6Ly/G3o9TFZE7VQWYuYbJBrAiCV2lQxJUIHapKv3WwAeHsDRdVcdhKvPcGLexY 0fUAGjABbGfxRk/QG0NP2xrbEC7zRExpzzVwjAQbvR+Nc61aS+/iINlBG+Z1NEnMoIP8 4lDiH7NZOVtf1kZI2KGnz60yH+LB49ls56D3JXNnTtkMFbM9dhwdHGB7LqICSxXxsh28 wibnk7h11DnZK0RCFkAxXaUK3e43SnPxBdosWwESG9oHT4UXRDp469YPQb/002pC4nmb 0FdF2PxQNCqpNGYO/5xT4pkGNkZyXEC0VrN1pTKlLXC1vgIMjSX6thDpqAMU4fb8+mhf em8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691760578; x=1692365378; 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=5paRZUGqJ3D1Mj/KW5eb90ngrh15fKmpdB5pZI/clCU=; b=cRrx7a+29hFNvo6EiCRozbGbegmqDM4+QQrw46WGSl7mwPSq2SKHlyXMRU41zC+ZFL 2ENWukZBHhy+6tJi9mmYJnTdVQAOM4EwltvhORbiRceWsydH9ZykOBnoR45JVora8Nw8 cRTVNGP+z9vSpV3imB+tWk1DrgqaDyV3xNEVrZ+Cka1HtC35T/DUdZYRX7VWV+Rtroeo a/LfOCEuRv/cul1G4KwSjUNl/p2ncBFqbAuz1m2MxTKNzD1q7pgMgi2mmHr+wafF0aSe Rk5C+mwCoAG9PdN2VlMqxoWVxnY1GTNDe28/+T55hvgUSAmE+iRnFEJp2vU8IFpAQx4n A+4w== X-Gm-Message-State: AOJu0Yyox6FJ6rjd0AHRm1OqB0QhOdx5DNK9z8uOtCblnK7RlfRuR3G6 XHly73xdE5oqeZgAxyVQA0XTvdOEpgY= X-Google-Smtp-Source: AGHT+IEHSjxnDZA2Sw/zHSSTr6lwRVhoVjM6uoNuM4ky0UDKGerEXrw/eIPOavZTmkHAy0bOKYlIzg== X-Received: by 2002:a17:90a:ad89:b0:263:fc43:5f39 with SMTP id s9-20020a17090aad8900b00263fc435f39mr1187684pjq.13.1691760577665; Fri, 11 Aug 2023 06:29:37 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id ei23-20020a17090ae55700b00262e604724dsm5199575pjb.50.2023.08.11.06.29.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Aug 2023 06:29:37 -0700 (PDT) Message-ID: <12fb5088-3f28-0a69-de1e-f387371a5eb2@gmail.com> Date: Fri, 11 Aug 2023 07:29:35 -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 Cc: gcc-patches@gcc.gnu.org, 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=-2.8 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 21:45, Palmer Dabbelt wrote: > > OK, that seems like the way to go.  I still think it's likely we'll need > to split up these types more, but that's something we can only deal with > when there's HW that behaves oddly. Yea, but I think we can fault this in as problematic hardware arrives. >> 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 ;-) > > I was thinking of some sort of "TARGET_ALLOWS_UNKNOWN_INSNS" hook, but > poking around the uses that might not be meaningfully simpler than just > rejecting these in the backend -- certainly simpler if we're just > worried about RISC-V ;) Not all ports have types at all. Some use types for things other than scheduling. It'd be a huge can of worms. > > This seems pretty mechinacial: just scrub through our MDs to check for > any un-typed insns, then add the assert and fix the failures.  You're > more than welcome to have at it, but LMK if you want me to try and find > some time for someone to do it -- certainly seems like a good way for > someone new to dig in a bit. Yes, definitely mechanical. And yes, it's a good way for someone to start to get familiar with these bits -- I used the lack of types on some of the bitmanip insns to help ramp up Raphael and one of the RAU guys in this space. Jeff