From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id 7EFAB3858C41 for ; Wed, 10 Jan 2024 19:16:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EFAB3858C41 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 7EFAB3858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::22e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704914175; cv=none; b=x0JBFp3B9/fTYM2QqybjB2/76M86d+cdXCHYtAt5XxjWyRZ1JGmTmuhgLBLfwKWM6jF96ppxpTadkTEsNXdKvNeFQR5ImNj/mKXe2CkxcgIKj+qFwwQrAOTfr9blwqEGWWkpGM7jmfOuLKe93ZoQ2L6y8c3tfwqpunedz3mWq/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704914175; c=relaxed/simple; bh=9tKKbH6lJw6EmNewIQayxwV9rBHkFUezXvDYxvR5Wj0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=EgIMjZeyShOlNV4xzpL8USenb0w9sXB5yclcL8N1CG7DLBsdwfYP/9Io6cqbHWUwYRJTTdRc0EwwUV8DWPUTFPpEYE+g6KTi39yVnfYmTL+NDSECxo2fKn3OJg1Gn+/O5pRAWZD2N66jD64skKSy/YYlP3l7h+dYUgQTX7c/mNY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2cd17a979bcso51015491fa.0 for ; Wed, 10 Jan 2024 11:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704914171; x=1705518971; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=m/ijr/EwacyD6ns60NazE7WF+OlBbEHOuG2sX5211g8=; b=K79yP0cJHBwj5r0mwN5B/BQD9atrOieds4X/HH5ErWjeIVnwiavjE2/qkbgdzhxzJX kR/b3iZYZwt/+wBNOsgjlpCZwfSBFlFIasrmt6eSY4PnlTZ0ri8jY0qNMcc4kc9EOv+0 zAeMMmYBWIYR2BM4iv2GJ4u5fLd6/mniV1AbCcKxP0JwtRgibmuDZ/tEiFuL8m9fo0Oz 5e/7j8Y29vH1FRVnnqUr2ImOC6ny5J6QM+bg8CvDHELlNrso41rXSEKy9PEe2iyL2LFS r7+tEgnjP4CttnDkQ0K6DvwIAtn9MCYRMEv//aYoNLBPtJWG6R/QJFu3p/ANXRbAM/M6 ic4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704914171; x=1705518971; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m/ijr/EwacyD6ns60NazE7WF+OlBbEHOuG2sX5211g8=; b=j0n4oUe17wpPpPf5wqCtRVpF3qf6NY2zVijbhPvLuC1uqw8BmASquk+5DId+v8qHwu Hut5E1rDUNQ6uEFGXxYIkCJAiujX1GekJckhyt1Cw9u3GyxVQh7MiLFMSKLuQZ9m1jwt /vQQMvyyCpUrmmbfuStpOmxhvItf1RryDA2ZIfqb+Afy9hCHsO3sQLAf9M+J7efAUru9 dpxnlBPnIjxy58oAVip3/Fd3IUCF/+nogg4anL/nsyypZ2x01acEsCryHTkeCxy39NXi R6RVE8/czcQarghoAqVM1w8Jz1vTBDWW17KFbcxEB5QHcj/Jlv6b3dqTfe+9PGPcc2FK bTqQ== X-Gm-Message-State: AOJu0Yz/1GoxvAh10K1xblHdcHS/Hfbe3A6/ROiziuem2GL7ZOqXlG5X oL6WdDqR62nNKcH2FG7P3V0= X-Google-Smtp-Source: AGHT+IGVdTESyPUujt8olCor+jlVTFeC1otJEIbVrqkIrr/N5b4c4e+ek5eR3qI6it9op2NwnkDfDQ== X-Received: by 2002:a2e:8815:0:b0:2cc:e3b8:3184 with SMTP id x21-20020a2e8815000000b002cce3b83184mr16757ljh.39.1704914170525; Wed, 10 Jan 2024 11:16:10 -0800 (PST) Received: from [192.168.1.24] (ip-149-172-150-237.um42.pools.vodafone-ip.de. [149.172.150.237]) by smtp.gmail.com with ESMTPSA id p24-20020aa7cc98000000b005532a337d51sm2251399edt.44.2024.01.10.11.16.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jan 2024 11:16:10 -0800 (PST) Message-ID: Date: Wed, 10 Jan 2024 20:16:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: rdapp.gcc@gmail.com, gnu-toolchain@rivosinc.com Subject: Re: [PATCH V2 2/4][RFC] RISC-V: Add vector related reservations Content-Language: en-US To: Edwin Lu , gcc-patches@gcc.gnu.org References: <20240110013159.2645757-1-ewlu@rivosinc.com> <20240110013159.2645757-3-ewlu@rivosinc.com> <04d6caef-f82e-4ff1-8d6f-df95062f1870@gmail.com> <8b74528a-3873-4c93-aea6-899f06c63e1a@rivosinc.com> From: Robin Dapp In-Reply-To: <8b74528a-3873-4c93-aea6-899f06c63e1a@rivosinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 List-Id: > Since all the pipelines should be tuned to their cost model, they > would be different anyway. If it would be simpler for now, I could > separate the files out. > I think I'm getting a bit confused. Is there a reason why we would > want to exchange scheduler descriptions like the example you > provided? I'm just thinking why a in-order model would want to use an > ooo vector model and vice versa. Please correct me if I got the wrong > idea. Yeah, the confusion is understandable as it's all in flow and several things I mentioned are artifacts of us not yet being stabilized (or actually having hard data to base our decisions on). Usually, once a uarch has settled there is no reason to exchange anything, just smaller tweaks might be done. I was more thinking of the near to mid-term future where larger changes like ripping out one thing and using another one altogether might still happen. Regarding out of order vs in order - for in-order pipelines we will always want to get latencies right. For out of order it is a balancing act (proper latencies often mean more spilling and the processor will reorder correctly anyway). So you're mostly right that the argument is not very strong as soon as we really know what to do and not to do. > I also want to double check, isn't forcing all typed instructions to > be part of a dfa pipeline in effect removing a situation where a tune > model does not specify a "vector tune model"? At least from my > testing with the assert statement, I get ICEs when trying to run the > testsuite without the vector tune model even on gc. There are (at least) three parts of the "tune model": - vector cost model, specifying the cost of generic vector operations, not necessarily corresponding to an insn - insn cost, specifying the cost of an individual insn, usually close to latency but sometimes also "complexity" or other things. - insn latency and other hardware scheduler properties. We can leave out any of those which will make us fall back to default values. Even if we forced a scheduler description we could still have the default fallback for the other two and generate unfavorable code as a result. However, this is of course not desirable and we will soon have a reasonable vector cost model that corresponds to the non-uarch specific properties of the vector spec. Once this is in place we will also want a somewhat generic vector scheduler description that goes hand in hand with that. Despite the name, the vector part of generic-ooo could be used for in-order vector uarchs and we might want to define a different description for out-of-order uarchs. That's a separate discussion but at least for that contingency it would make sense to easily interchange the scheduler description ;) Regards Robin