From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 59C1C3858402 for ; Tue, 29 Aug 2023 13:47:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 59C1C3858402 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-pg1-x530.google.com with SMTP id 41be03b00d2f7-565334377d0so2841868a12.2 for ; Tue, 29 Aug 2023 06:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693316836; x=1693921636; 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=xpdkwxI1ECQwi4hyvj0G+mPTlswlkt7v6Uc0Zqn6MA0=; b=kzdsW/XzHYHu+eQJx+E10G+0FqSZ4KLoUXm8npttlfiM3oLyCPzhJfVMLjrg425jGX pHgttldPTNehznLftlgjU6xrAWyeFUgNlLHNGcM6owG9jEZda4IL0QqzVuUVuPkkWLrk kh67/FIJ5uc/pUAY5F2akHN+SvaTuiuDjqs7K/21lcsj8zOvVzGLRe/jC81K7qTfC3CV mq7zW9CmXAetNqKm9xm0/aLy00QY0MenLx5AP9oMn0j3qcwz1KSNCAnAB80ICh7Eobw5 tAIvQ3JVXHG9Ksa7uQvv5aNgY6+hPrZ9d/SXUj/RhHjIIqWGZ3UcIBLBqyfdnGnEU+54 BKpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693316836; x=1693921636; 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=xpdkwxI1ECQwi4hyvj0G+mPTlswlkt7v6Uc0Zqn6MA0=; b=k6y5BdjQpbjnxc3M83JmzNZ8zeUBFYtL37yThOChCwEx0+1kdx6eXJxRzn4TsLc6OQ Jo5erQF3klT5y4x/nOYvHtcFtRhGCZ+k3AOSVK75xGzRLtuZSNWkE3JQLVll7Nfsqpqd U0PfIsNAjdY5CVe8ag6kOBR9Axulf0CI/WiMlWjrouWTE1nRrExqJNer0a7Bhccg//Ni F9gUN1Yy+k/Fx6oQu2kmRTNUml+JGSEuMBybspwrV5TN1neupxFphV0e3x2l73oCqcwg p7l0RjhRmeVQgzIeDgSNfxQG1v2KSkafSfwnKAcO1eHD//YHq7nEJvpZS+RIbA+gRbj2 ZUwQ== X-Gm-Message-State: AOJu0YxMVaW8esuIGo3E4TIsw0ZJXmsH/TqAWIxgWhHYyrB5tIRXf2rm uY9VNEWROlW9dWcX7B3+ail/AF8YewY= X-Google-Smtp-Source: AGHT+IGpkecrcAbWfFv25MeT7kVCrONLqVdD1s8sKI4ilAc4N+Ln/OowYeXxs4VGKaxS6NyB5X30Zw== X-Received: by 2002:a05:6a21:6da6:b0:12e:73bb:cbb6 with SMTP id wl38-20020a056a216da600b0012e73bbcbb6mr35247173pzb.14.1693316836175; Tue, 29 Aug 2023 06:47:16 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id q15-20020a62ae0f000000b0068a538cc7adsm8484494pff.52.2023.08.29.06.47.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Aug 2023 06:47:15 -0700 (PDT) Message-ID: <690e3625-3974-f56a-2400-ee952b3c4194@gmail.com> Date: Tue, 29 Aug 2023 07:47:14 -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 1/1] RISC-V: Make "prefetch.i" built-in usable Content-Language: en-US To: Tsukasa OI , Kito Cheng , Palmer Dabbelt , Andrew Waterman , Jim Wilson Cc: gcc-patches@gcc.gnu.org References: <97c0d824fa5aeaee52a825da7f7a17ae8616c5ab.1691636916.git.research_trasio@irq.a4lg.com> <5b7219c9-76d6-574b-a7e4-2e0992a56198@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,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/28/23 20:09, Tsukasa OI wrote: > On 2023/08/29 6:20, Jeff Law wrote: >> >> >> On 8/9/23 21:10, Tsukasa OI via Gcc-patches wrote: >>> From: Tsukasa OI >>> >>> The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly >>> broken so that practically unusable.  It emitted "prefetch.i" but with no >>> meaningful arguments. >>> >>> Though incompatible, this commit completely changes the function >>> prototype >>> of this built-in and makes it usable.  To minimize the functionality >>> issues, >>> it renames the built-in to "__builtin_riscv_zicbop_prefetch_i". >>> >>> gcc/ChangeLog: >>> >>>     * config/riscv/riscv-cmo.def: Fix function prototype. >>>     * config/riscv/riscv.md (riscv_prefetchi_): Fix instruction >>>     prototype.  Remove possible prefectch type argument >>>     * doc/extend.texi: Document __builtin_riscv_zicbop_prefetch_i. >>> >>> gcc/testsuite/ChangeLog: >>> >>>     * gcc.target/riscv/cmo-zicbop-1.c: Reflect new built-in prototype. >>>     * gcc.target/riscv/cmo-zicbop-2.c: Likewise. >>> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md >>> index 688fd697255b..5658c7b7e113 100644 >>> --- a/gcc/config/riscv/riscv.md >>> +++ b/gcc/config/riscv/riscv.md >>> @@ -3273,9 +3273,8 @@ >>>   }) >>>     (define_insn "riscv_prefetchi_" >>> -  [(unspec_volatile:X [(match_operand:X 0 "address_operand" "r") >>> -              (match_operand:X 1 "imm5_operand" "i")] >>> -              UNSPECV_PREI)] >>> +  [(unspec_volatile:X [(match_operand:X 0 "register_operand" "r")] >>> +    UNSPECV_PREI)] >>>     "TARGET_ZICBOP" >>>     "prefetch.i\t%a0" >>>   ) >> What I would suggest is making a new predicate that accepts either a >> register or a register+offset where the offset fits in a signed 12 bit >> immediate.  Use that for operand 0's predicate and I think this will >> "just work" and cover all the cases supported by the prefetch.i >> instruction. >> >> Jeff >> > > Seems reasonable. > > If we have to break the compatibility anyway, adding an offset argument > is not a bad idea (though I think they will use inline assembly if a > non-zero offset is required). > > I will try to add *optional* offset argument (with default value 0) like > __builtin_speculation_safe_value built-in function in the next version. The reason I suggested creating a predicate which allowed either a reg or reg+offset was to give that level of flexibility. The inline assembly would specify an address. If the address was already in a register, great. If the address is expressable as reg+offset, also great. If the address was a symbolic operand, the right predicate+constraint should force the symbolic into a register. Jeff