From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 37A67385802E for ; Wed, 10 Jan 2024 22:39:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 37A67385802E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 37A67385802E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704926384; cv=none; b=IQWKqDSH9q6zTImptqV8SxrVFLOsfUhEvPEaEuhCY7F3Iie+Z1yKCKAb3ZtJ6qW/Qs/o2QHgQ1EFaruJDr9zJaOKx3Yh1BFodD4fPw0inPDjqLrNWkpwBi3koTZ8BVjdgF/J3XQ9FpCKTKFjBcLA6fzjTr7R67ZvzRgYiGayGI4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704926384; c=relaxed/simple; bh=4JSI8kJAMVYnxRUSkmeO3aZFCs03NhGhJ7I0RIURMEs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=WtnBs94/4mt42Pz6SthLEATofwoIB+N2mK9JbjDkPTy9yekoPdRQpY7Sep72jtPmIqdLqUgaTwg7t0Xr7IewGvAJB79ddP2dNvv3iiTfjiqLWx3uCEqD3Oi59r5a0fEn8vFqVE2y62OCM1uSXGthFDiMfwt7ngCaahXPZXrTy/M= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1d45f182fa2so40461325ad.3 for ; Wed, 10 Jan 2024 14:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1704926381; x=1705531181; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:newsgroups:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SITm8wJ/kYUHb5DYsFHKCepykQrMuvQHrAwhzlWBjWA=; b=0R/j+kk1jbs31mHpaVZSc1vi3yU6Sw+Cg7rNEsoh9jdB8s5DQCL3WhhvaT75QYz7B/ g0SOxjn63Sd8ApT/3dEXK6G06UDQas2O/rqIxoKgW0br5O5d+y/E5+YUeM8M+FqsJldt rQuxZ09LILSbI+cthPeCRca8HCh2kJa4r1MFbRgR1u2gF48jRq+Ko77OVrkm5DsmiuDB 4yDRU2/808Y/8wsLV0r+4Hm1SjlDnqNqPHL1zxxHRPh8S6CFZX/l9iKkFEdgjfrKB2nQ SrBNJ4Z5wRskM8J2R8vWTYDVu/4BFtxP0PAucXV5k1Bm5JMotG3JsU1uzBeVWr32EU6K tMfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704926381; x=1705531181; h=content-transfer-encoding:in-reply-to:from:references:newsgroups: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=SITm8wJ/kYUHb5DYsFHKCepykQrMuvQHrAwhzlWBjWA=; b=jaybhCY1hDDBISkroGzceZX/cty6RauoGcUFufBZV0NZyxIFVWftMBU1WNRWcCbH6g lsvduSTpTPMDSMHHsGCa/iPQfhMnD06KfEk4h5dVDUObO7K01AYdI0y7YGqD39a3c9mb lZfoxmFk3GMCij1UD2mb/prBTeOl1VIwzHtiHvd+bAlFiWWgCajgzhzjRmEFLLypwXxn WJT8JSuWDWiZviVilADqjhmNeOpYiGqQqewJo1GTD5W8ytcIVviBWr9isRFzwsr72gWp 3yv/E712xEknK4R987joVLcWVIy4HPxnegWJrfy9ugB4lQAa6+AuiBiIhT7vqoo+dJYW 1iZQ== X-Gm-Message-State: AOJu0YyvWzqeVJWgOXohUJLEcPr72mIpanAUIzFvdLCqkWS5afPOubaX 5HST6ckMVpAjtaXGHpCRmZoBUmb8v7GtUg== X-Google-Smtp-Source: AGHT+IG7EUnW45rL9xPacPLQmo4RP8ECu/vQzQ3pV8z8Aqu9YjYnYL2U6d5EyOA1Dpu4/4HNg7Oslg== X-Received: by 2002:a17:903:1104:b0:1d3:b258:e02d with SMTP id n4-20020a170903110400b001d3b258e02dmr310862plh.105.1704926381120; Wed, 10 Jan 2024 14:39:41 -0800 (PST) Received: from [10.0.17.83] ([12.44.203.122]) by smtp.gmail.com with ESMTPSA id p3-20020a1709026b8300b001cfde4c84bcsm4137977plk.141.2024.01.10.14.39.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jan 2024 14:39:40 -0800 (PST) Message-ID: <688eee4b-325c-4d81-a090-c67874ed1c00@rivosinc.com> Date: Wed, 10 Jan 2024 14:39:39 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2 2/4][RFC] RISC-V: Add vector related reservations Content-Language: en-US To: Robin Dapp , gcc-patches@gcc.gnu.org Cc: gnu-toolchain@rivosinc.com Newsgroups: gmane.comp.gcc.patches 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: Edwin Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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. > That makes sense to me! >> 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. > So if I'm understanding things correctly, the costs the Juzhe is working on in riscv.cc would be part of the vector cost model since they don't correspond to individual instructions and only target vector code. These costs would be the default fallback in the event of having no scheduler descriptions for the insn. The vector pipelines I'm working describes the insn latency categorized by the insn type. The scheduler will attempt to generate favorable code by this description but also consider the vector cost model. That is, it's possible for an insn with a latency of 1 and cost of 10 to be replaced by an insn with a latency of 2 and cost of 3. The insn cost is the cost of every insn which can be specified elsewhere. These override the values in the vector cost model for vector insns? Where are these specified? Then, all of these combined form a tune model like generic-ooo or rocket. > 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 ;) > I think I understand everything. I'm currently testing a run with a generic-vector-ooo file and I'm a little unsure how we would create a second generic-vector-in-order file such that each insn maps only to one reservation without using tune attributes but I guess that will be an implementation detail for later :) Edwin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 2E8CB386C5BF for ; Wed, 10 Jan 2024 22:39:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2E8CB386C5BF Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2E8CB386C5BF Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=116.202.254.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704926392; cv=none; b=YY2pmFaIeSlH2PS0mm03x+kasugMMOVKsfMImg/PQAZjjbiHhbtpQp/oMz7VLz9r0hFvSGaRjLi32CNgJFEnYopIdH/zO87Ykiy2SXV/7k394//SLOi71crjnUzZE8yZ8/ks5m/jGQ2as+iweZNGf/Dr6yOcZM8ATCJ+UM9HTL0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704926392; c=relaxed/simple; bh=4JSI8kJAMVYnxRUSkmeO3aZFCs03NhGhJ7I0RIURMEs=; h=To:From:Subject:Date:Message-ID:Mime-Version; b=so3HtoLzdbmv0tfdX8yl9txPHMeJcakOqXCmRtWBTBdGBZeWLB4RgAbeWHg7mKQrjxxcOJwXHVk5hEveuogbXULTGIjmc/4JtGj2nKbXiLmgZE1lf0+OdpxBeTDoK1O179X2oj5OY3AKJ/RCZJi3VRkXP0ZKcUz+6T9/tRgO9iY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rNhEi-0009DH-Bz for gcc-patches@gcc.gnu.org; Wed, 10 Jan 2024 23:39:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Edwin Lu Subject: Re: [PATCH V2 2/4][RFC] RISC-V: Add vector related reservations Date: Wed, 10 Jan 2024 14:39:39 -0800 Message-ID: <688eee4b-325c-4d81-a090-c67874ed1c00@rivosinc.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla Thunderbird Cc: gnu-toolchain@rivosinc.com Content-Language: en-US In-Reply-To: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20240110223939.23Vk8b8pjm4mHW_KO5QX92LatcjTDYDb4i3KrD6TLTA@z> >> 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. > That makes sense to me! >> 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. > So if I'm understanding things correctly, the costs the Juzhe is working on in riscv.cc would be part of the vector cost model since they don't correspond to individual instructions and only target vector code. These costs would be the default fallback in the event of having no scheduler descriptions for the insn. The vector pipelines I'm working describes the insn latency categorized by the insn type. The scheduler will attempt to generate favorable code by this description but also consider the vector cost model. That is, it's possible for an insn with a latency of 1 and cost of 10 to be replaced by an insn with a latency of 2 and cost of 3. The insn cost is the cost of every insn which can be specified elsewhere. These override the values in the vector cost model for vector insns? Where are these specified? Then, all of these combined form a tune model like generic-ooo or rocket. > 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 ;) > I think I understand everything. I'm currently testing a run with a generic-vector-ooo file and I'm a little unsure how we would create a second generic-vector-in-order file such that each insn maps only to one reservation without using tune attributes but I guess that will be an implementation detail for later :) Edwin