From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id B55323858001 for ; Wed, 10 Jan 2024 13:36:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B55323858001 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 B55323858001 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::535 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704893806; cv=none; b=b77/ydfWPTwij2RzmQKa822YqV9bbjGypYLR/1hrpjDPU87aMpx285GvHaCcSRkvZSsUMAyOI1N3fArmemM1vcM35lfIeZBL7jqqb8Kw0n5gtLrM2kyY+fOUH431k6vGgmSxDQCbbQh4NIQVq6j+PxAacCbm6uuXyElSqOPyLgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704893806; c=relaxed/simple; bh=flsjgr9iLuigoOlMWK65jGK3vp+ZvWF3t1XfgkzO6Hc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=GzhzlKSGhSbgYeR9oFFMAVhQ9WhMwwc5wJ6QZzp+RPaDHSbC37mIUBukSwuyKzx4VrRCnwzJ6DwjCvZN95qZxGItHfsmF1MIcnTKlUWSodxowtwVPYQpFeUH2ZAxnWBDy+Q6QPJKoVNjb9S9yASzsLLkhyh/Z97iQSZSez52QS8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5537dd673e5so3524090a12.0 for ; Wed, 10 Jan 2024 05:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704893799; x=1705498599; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=uv728DB93V+BFK6AaFDjXvDZK1Vz/nOPsIsQ1WW2ngs=; b=ZnE7a3YQ0fnmaOaC6mYlLfwNkTHfsM3FBCPtoHgJdcFHF7XYz5M999/q3EGjuvCgVn JfGxYlSzxN5YQBMoLxkuctFUxmOxqVyFCM84ut01xennCoOcYX1q9ljmnSpUzQLIbQx1 ZJhjtcM1q223D9GvBxurqeJ0WXyiAL6B/ULFrWAl4FN+7HP1kbwWYvibzJ8vKsMnX+/u Yvf3DuN3c21KMy+0WJEqZBWunOyRd+dqRVly+DhJi0+moh+GKBcUYhjuNhxS5Kc17ggM CUNse+0oO07sGlThazLtUZKzyso/7kfJf4YnhtNeZJ7g0fus14uuGenWswoS185S6Cla lqMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704893799; x=1705498599; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uv728DB93V+BFK6AaFDjXvDZK1Vz/nOPsIsQ1WW2ngs=; b=jGjoXJXWylxK5BLNUAHyp9S0DoVVxJyJvxhTGpIYVg2YCue9jRsrNfkztt8lXFPuLH YrI6ekT0RlAf8y0qOShFuJ2sTAIUblhBtw9qA5UwO/fO0bzz0XTQk9Rzlkwwom9W4fwb hOOXfdjPGSuCOU6Ni2M+96BQiTpka0j/sPeOufNpA7eu674R+oT3HBztb+vtxe2c2JZY Mglu2c4J4loV/85ftFzRMbB8AZyCn3UphrDtE68JliwN93Czqgi1c1K0P0qJqIcrh4Sm WYHGrwTDQ8wh959TvuZEr30S8oqn08L3sig9mA3W/s89WsoQrzzR3BYtYHDDwbKAKH0m VERA== X-Gm-Message-State: AOJu0Yz30bN+nWWZhXpqNM7css9j35xGPzpJ1IZ2AKvsOjgI9+xz9KAq Fq65UPhyy8z1HkzCuQgmLu0= X-Google-Smtp-Source: AGHT+IHZCULQ5JNpMWgCOhxoedfzZTVF04E1tGzOsmozdjmhBegBEOFyoyx30EgZOFHgjr56cC2VFg== X-Received: by 2002:a50:9e61:0:b0:557:1006:40a8 with SMTP id z88-20020a509e61000000b00557100640a8mr435636ede.5.1704893799078; Wed, 10 Jan 2024 05:36:39 -0800 (PST) Received: from [192.168.1.23] (ip-149-172-150-237.um42.pools.vodafone-ip.de. [149.172.150.237]) by smtp.gmail.com with ESMTPSA id e7-20020aa7d7c7000000b00554d57621eesm1992604eds.90.2024.01.10.05.36.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jan 2024 05:36:38 -0800 (PST) Message-ID: Date: Wed, 10 Jan 2024 14:36:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: rdapp.gcc@gmail.com, jim.wilson.gcc@gmail.com, palmer@dabbelt.com, andrew@sifive.com, philipp.tomsich@vrull.eu, jeffreyalaw@gmail.com, christoph.muellner@vrull.eu, juzhe.zhong@rivai.ai, Jin Ma , Xianmiao Qu Subject: Re: [PATCH v5] RISC-V: Fix register overlap issue for some xtheadvector instructions To: "Jun Sha (Joshua)" , gcc-patches@gcc.gnu.org References: <20240103075409.1790-1-cooper.joshua@linux.alibaba.com> <20240110065111.1185-1-cooper.joshua@linux.alibaba.com> Content-Language: en-US From: Robin Dapp In-Reply-To: <20240110065111.1185-1-cooper.joshua@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 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: Hi Joshua, > For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions > and floating-point compare instructions, an illegal instruction > exception will be raised if the destination vector register overlaps > a source vector register group. > > To handle this issue, we use "group_overlap" and "enabled" attribute > to disable some alternatives for xtheadvector. > ;; Widening instructions have group-overlap constraints. Those are only > ;; valid for certain register-group sizes. This attribute marks the > ;; alternatives not matching the required register-group size as disabled. > -(define_attr "group_overlap" "none,W21,W42,W84,W43,W86,W87,W0" > +(define_attr "group_overlap" "none,W21,W42,W84,W43,W86,W87,W0,thv_disabled,rvv_disabled" > (const_string "none")) I realize there have been some discussions before but I find the naming misleading. The group_overlap attribute is supposed to specify whether groups overlap (and mark the respective alternatives accepting only this overlap). Then we check if the groups overlap and disable all non-matching alternatives. "none" i.e. "no overlap" always matches. Your first goal seems to be to disable existing non-early-clobber alternatives for thv. For this, maybe "full", "same" (or "any"?) would work? Please also add a comment in group_overlap_valid then that we need not actually check for register equality. For the other insns, I wonder if we could get away with not really disabling the newly added early-clobber alternatives for RVV but just disparaging ("?") them? That way we could re-use "full" for the thv-disabled alternatives and "none" for the newly added ones. ("none" will still be misleading then, though :/) If this doesn't work or others feel the separation is not strict enough, I'd prefer a separate attribute rather than overloading group_overlap. Maybe something like "spec_restriction" or similar with two values "rvv" and "thv"? Regards Robin