From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id C154E3858C27 for ; Mon, 28 Nov 2022 18:02:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C154E3858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pl1-x629.google.com with SMTP id d3so5944913plr.10 for ; Mon, 28 Nov 2022 10:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=SmkvRwI99sxvEgf/1dyTzVgRsuQLqXVZb+mxRqk6Daw=; b=5IE9aN2SBEFlij0Lh1gkrTVPfsJpxXY88ry5j+83CsOQrm4W+VBB/rhNwFBCu1QRKe pXOpzXZqSjEuTyhiYdfGy4ZImdmwmFTSsa63ME6ZH90NodrTHbuuXJuO05XtfTj8Jf7f yAMPtamYgrQByAGssn40NgaUMBpcZlYFeunIZNNX5gLAnlUzymFQWez68bHyOhgN+pFl QcPK75+X36Dc9RAPogrJt4sX5hUyTMowTUmXwcakMVeZ8dN0RU0jo00UlepCvpiZvAAc Kqs/MxaB5NhGEtJMih49lfan4WrxsRfok/8K282iDHYwBlkMAhZDjTqFLGJ1TXgH+ok6 97sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SmkvRwI99sxvEgf/1dyTzVgRsuQLqXVZb+mxRqk6Daw=; b=eoNX/aFlpiH/U8QhRIXOU53aMbCjsYRih8LW5bDIaoAK4kQfwBiDFX0i5FHYbbrV68 +Vllqlasl43yVPk3E3g0+Xb4+7taPDqwBljsZNUZJVLlqQQObYxbw4qIkdk/56JCBERc odma7EaadKsPIb0MDCkhR9vCxGysSYPhkELWWpCSjZdCFc1nFw2ozvfzqa8p23ezbOsw corfVqP91tPf88uLodwoYdEExWPpVbTdLgl8+aIKSNYJVu+PjOUjhHUcWWfNYtWCtIEF kBl/2XBUH6Cr9nix4XqVZ2EUBcyAWHMGzqCY4goZ48dL+tN4Df5YOsbIpLDF/ESY39GJ dvfg== X-Gm-Message-State: ANoB5pmVw/+Oz6bK7Ag4v/3dkDRKArLQMi+nqTg7PpxDUA0SvyMPQ7Mx C9Fz2s6PloWimenTMvqAxm1Qhg== X-Google-Smtp-Source: AA0mqf4zAO0TcFElBEeKDkCem555ai3J2rMj076g/FuqVHwoghJcwzAsfbEPt3bzsgW7jrthqhMXyw== X-Received: by 2002:a17:902:ead2:b0:186:6e16:18dd with SMTP id p18-20020a170902ead200b001866e1618ddmr33879513pld.131.1669658532436; Mon, 28 Nov 2022 10:02:12 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id x127-20020a628685000000b00572275e68f8sm5238770pfd.166.2022.11.28.10.02.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 10:02:12 -0800 (PST) Date: Mon, 28 Nov 2022 10:02:12 -0800 (PST) X-Google-Original-Date: Mon, 28 Nov 2022 10:02:03 PST (-0800) Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS In-Reply-To: CC: juzhe.zhong@rivai.ai, gcc-patches@gcc.gnu.org, Kito Cheng From: Palmer Dabbelt To: jeffreyalaw@gmail.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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 Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreyalaw@gmail.com wrote: > > On 11/28/22 07:14, juzhe.zhong@rivai.ai wrote: >> From: Ju-Zhe Zhong >> >> gcc/ChangeLog: >> >> * config/riscv/riscv-protos.h (enum vlmul_type): New enum. >> (get_vlmul): New function. >> (get_ratio): Ditto. >> * config/riscv/riscv-v.cc (struct mode_vtype_group): New struct. >> (ENTRY): Adapt for attributes. >> (enum vlmul_type): New enum. >> (get_vlmul): New function. >> (get_ratio): New function. >> * config/riscv/riscv-vector-switch.def (ENTRY): Adapt for attributes. >> * config/riscv/riscv.cc (ENTRY): Ditto. >> * config/riscv/vector.md (false,true): Add attributes. > > I'm tempted to push this into the next stage1 given its arrival after > stage1 close, but if the wider RISC-V maintainers want to see it move > forward, I don't object strongly. I'm also on the fence here: the RISC-V V implementation is a huge feature so it's a bit awkward to land it this late in the release, but on the flip side it's a very important feature. It's complicated enough that whatever our first release is will probably be a mess, so I'd prefer to just get that pain out of the way sooner rather than later. There's no V hardware availiable now and nothing concretely announced so any users are probably going to be pretty advanced, but having at least the basics of V in there will allow us to kick the tires on the rest of the stack a lot more easily. There's obviously risk to taking something this late in the process. We don't have anything else that triggers the vectorizer, so I think it should be seperable enough that risk is manageable. Not sure if Kito wants to chim in, though. > I'm curious about the model you're using.  Is it going to be something > similar to mode switching?  That's the first mental model that comes to > mind.  Essentially we determine the VL needed for every chunk of code, > then we do an LCM like algorithm to find the optimal placement points > for VL sets to minimize the number of VL sets across all the paths > through the CFG.  Never in a million years would I have expected we'd be > considering reusing that code. > > > Jeff