From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id 3270C3857BB3 for ; Wed, 23 Aug 2023 23:26:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3270C3857BB3 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-oi1-x22e.google.com with SMTP id 5614622812f47-3a81154c5f5so4074983b6e.1 for ; Wed, 23 Aug 2023 16:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692833216; x=1693438016; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mo4dSNCD9cOC3gM8ty/zb0ZC/0XRrjRhWt9ZKTzpKFY=; b=QicCUmO/Y7YHK6aIo1Nb0IwvjJOznPuLRGbNxeMlrQD8lx35WuroGB38CxHx2v2Yq5 DqSHXcAX9LWJaV9RhfCch9tT8GtsTb2JivDhCmF8XOV3JFegzh1Ag0ydplNEVar4OAM1 9x4f4tRkXAGwJcX5RKOY5In+9aEKHa1P8u2GQhSoZHa6vPEsaI85qMfdhWE59kd/+KTE KjY5GQHVoI8PTzMnXugAXkLjm1J/uuCJz7Rn19UpP0hxfWb6o07jKbf/hKuSTvnrQ3s6 5CUxORX8Dh2+N9oNB/spvETePb662t4LVVZ5+8CEhTS0i1hy8dOUr8jWI2MICTd6jzi8 Sxmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692833216; x=1693438016; h=content-transfer-encoding:in-reply-to:from:references: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=mo4dSNCD9cOC3gM8ty/zb0ZC/0XRrjRhWt9ZKTzpKFY=; b=f/iM44llb9TCji4lfs78zMQnEAZ4WMVjwBKQ5G6GN7gDem4g0AI3dke/y7W3yrIuOV 2vYUji6z2/LgQzPtSF4B96OArN3+PVW2MaIAYlSPcNqHscds1s0O2T0qCKfANcH+uuEh FIZIP/VWDI1Y/YCdYBlAydSaKZvtysGrd6DtsUvBTfpeF7QhfxAi4rf97e+pPgySD5Mx LQC9IeqxqzAp9JhDcwZQsLPMoDVSwOdvarOfZLcy0ASW9MQOZEj4xq3C9MDlX90H3655 hAdu9XIjJ2KSJzP7Htnt+7VKmO/KULBKovgZ7JDUTzRq8dS7UT9OvmmLQvmeEqWq//2e 24hQ== X-Gm-Message-State: AOJu0YzsexeYOztw6EZUAmaC3jrq8BxGzxedCSWOtXnPOG9fO/yuQqnY vWtzdIJip/tdm6+MbXtOH50= X-Google-Smtp-Source: AGHT+IHiwT5tdnlK8lLZtTyg5Zz2Ne5LnqFEo/r3Kd7uB0w35jE6IhQrl08tLRaRjpgksf2g2rJzXg== X-Received: by 2002:a05:6808:1988:b0:3a3:d7de:5cfa with SMTP id bj8-20020a056808198800b003a3d7de5cfamr17784523oib.11.1692833216326; Wed, 23 Aug 2023 16:26:56 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id v10-20020a63b64a000000b0055387ffef10sm9167381pgt.24.2023.08.23.16.26.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Aug 2023 16:26:55 -0700 (PDT) Message-ID: Date: Wed, 23 Aug 2023 17:26:54 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook Content-Language: en-US To: "Li, Pan2" , "gcc-patches@gcc.gnu.org" Cc: "juzhe.zhong@rivai.ai" , "Wang, Yanzhang" , "kito.cheng@gmail.com" References: <20230821072627.3984748-1-pan2.li@intel.com> <995842b2-2765-24d5-466e-4588dcdcc48e@gmail.com> <951fced9-f798-f9b6-7827-14447a93d1c9@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 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: On 8/23/23 08:54, Li, Pan2 wrote: > Thanks Jeff for comments. > >> Understood. So the natural question is why does x86/sh not need this >> for its mode switching? Don't all the same issues exist on those >> targets as well? > > AFAIK, it comes from the different design principle between the risc-v and x86/arm intrinsic API. > The risc-v rvv FP rounding mode intrinsic API has one abstract level above the insn itself, while > the x86/arm only indicates the semantics of the insn. > > For example, if one vector instruction VFADD doesn't have static rounding mode (aka encoding rm in insn), > there is no such a intrinsic API contains rounding mode argument in x86/arm. While the risc-v fp > vector intrinsic will always have static rounding mode API if the frm is honored. > > In short, the risc-v intrinsic API is closer to the end-user, while the x86/arm instrinsic API is closer to insn itself. OK, but I'm still strugging to see how the distinction is important here. Ultimately there's a state at a call site. We need to make sure that state from the current function doesn't impact the callee and we need to make sure that the callee doesn't impact the state in the caller. That implies a save/restore pair around the call (possibly optimized so that we minimize the number of save/restores). I would have expected x86 to already be doing this. But maybe there's some ABI thing around mmx vs x86 state that allows it to be avoided.... > > For the rest part, will have a try based on your suggestion soon as I am in the middle of something. No problem. Get to it when you can. I think it affects you more than me :-) jeff