From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id A471F3858C2D for ; Thu, 31 Aug 2023 09:16:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A471F3858C2D 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-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-52a06f5f556so714358a12.2 for ; Thu, 31 Aug 2023 02:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693473371; x=1694078171; 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=CNbDOX3dngS+MESq/Uc+zLEKlOjsUAkvI9b3DMA7Bdc=; b=AyrHxvw862SLBf86i/05fFgqVH+/nGEOM/B4+t5ZFutWzzcjFxpbygE9g2enV5c+xR Z/ss5PmiF99r3hWDs9f39ygsG/xdfjXIDZ/ZyFP/yS40BHkUeGuid/fJhShaXGkm93ad CWvVLOynXQO/GiJHcZtf38V/+uZoJH3+7H2WfMqeY9jnGL7v18RqooryIwqucCS1Gt4w XXNFlmEsxb5j0UDyTv/HOnAOkgctw38/TIBMQtTAPPWQAzrdHYiGJOEqW7xX+khFIb/K JSoYFoXZahPwqaveqq0mKnSxgKqUWR49Edhzpx+thG0sTPWkeolWilGICIxVHrN2hfJL U44Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693473371; x=1694078171; 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=CNbDOX3dngS+MESq/Uc+zLEKlOjsUAkvI9b3DMA7Bdc=; b=LmyVboCVwbbuQRj7obZQcgm46nL4X+d8h+S6xhrgG1KbEVr+muzIrgJaHTnH5sEU4/ XipIf3UM2iyYS7i4ufnm/AhAEk4QIXWLYt4gioA9eleine1OykQJk9S3Qi8CAZWgLCXE hVs8RiWfmOYPlPdWsGrOIhFf/tE6pZwKVmfA6OFOStz8To5qiRfovMNsGc7UpTYlZ/Nx uj2sAt3T2xIAvSWS2lzCYlnDvJgVdu1D6rAM75CUjzLztI9aEszHMuTLCsmsAVusO3MH 3vSUC+q4jC/szihWAb2TDSpU10NRo++brzNL78ootJISWEK6zGcoZr2/B1zkiiNzUM9m BKwA== X-Gm-Message-State: AOJu0Yz15ZevjMaA2ttdUJcqBbhs1DNfQMQ8nfdZVlV8pTaHV8cEJqsf AgL2mHZd7a91GTN7yZN7000= X-Google-Smtp-Source: AGHT+IHNmejmUcCG8qyLhf7+XhHSoi2xnbTwdffTawsqvCDOarxgYSX28KwRRYObf3F1C+b3kRFMpQ== X-Received: by 2002:a17:907:2c67:b0:9a1:f415:7c24 with SMTP id ib7-20020a1709072c6700b009a1f4157c24mr2918497ejc.46.1693473371162; Thu, 31 Aug 2023 02:16:11 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id z7-20020a1709060ac700b0098d2d219649sm542659ejf.174.2023.08.31.02.16.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Aug 2023 02:16:10 -0700 (PDT) Message-ID: Date: Thu, 31 Aug 2023 11:16:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: rdapp.gcc@gmail.com, juzhe.zhong@rivai.ai, kito.cheng@gmail.com, palmer@rivosinc.com, jeffreyalaw@gmail.com Subject: Re: [PATCH] RISC-V: Refactor and clean emit_{vlmax,nonvlmax}_xxx functions Content-Language: en-US To: Lehua Ding , gcc-patches@gcc.gnu.org References: <20230830115327.1296036-1-lehua.ding@rivai.ai> From: Robin Dapp In-Reply-To: <20230830115327.1296036-1-lehua.ding@rivai.ai> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 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: Hi Lehua, thanks, this definitely goes into the direction of what I had in mind and simplifies a lot of the reduntant emit_... so it's good to have it. I was too slow for a detailed response :) So just some high-level comments. One thing I noticed is the overloading of "MASK_OP", we use it as "operation on masks" i.e. an insn as well as "mask policy". IMHO we could get rid of UNARY_MASK_OP and BINARY_MASK_OP and just decide whether to add a mask policy depending on if all operands are masks (the same way we did before). Related, and seeing that the MASK in UNARY_MASK_OP is somewhat redundant, I feel we still mix concerns a bit. For example it is not obvious, from the name at least, why a WIDEN_TERNARY_OP does not have a merge operand and the decision making seems very "enum centered" now :D In general we use the NULLARY, UNARY, BINARY, TERNARY prefixes just to determine the number of sources which doesn't seem really necessary because a user of e.g. NEG will already know that there only is one source - he already specified it and currently needs to, redundantly, say UNARY again. If we split off the destination and sources from mask, merge and the rest we could ditch them altogether. What about emit_(non)vlmax_insn (icode, *operands (just dest and sources), mask, merge, tail/mask policy, frm) with mask defaulting to NULL and merge defaulting to VUNDEF? So ideally, and in the easy case, the call would just degenerate to emit_..._insn (icode, operands). I realize this will cause some complications on the "other side" but with the enum in place it should still be doable? No need to address this right away though, just sharing some ideas again. Regards Robin