From patchwork Fri Oct 14 19:56:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Palmer Dabbelt X-Patchwork-Id: 58871 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DFA01385275C for ; Fri, 14 Oct 2022 21:57:40 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id D031B3858D38 for ; Fri, 14 Oct 2022 21:57:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D031B3858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pf1-x432.google.com with SMTP id f140so6102261pfa.1 for ; Fri, 14 Oct 2022 14:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=to:from:cc:content-transfer-encoding:mime-version:message-id:date :subject:from:to:cc:subject:date:message-id:reply-to; bh=p2M/qvXY4aKxeNNCaonXV2+iQxI4fghjZqtnhUD9h+Y=; b=1eafGZDEWJLTkajdU7pE6E+59VYV1MpFekbreC0sSc2WUysTYVUy6gO9AHLn9MdKRW 8Poi3+Hr4Zy30M1WMNTo1pbSlG9qSNmGU/aI1EIU9DtWoIA7287g30vOs1+FvGLMPEBp E9lhIwTAROvPo51KyTP9vHwL8sF+YnQWdzLYGIxR8Pzw6G9ru5DhelwlJByr6Ue5N0qP ZHZKPG65jjmv3L1xjxIwLF0L4Zbj2xugdi5vRDiNJGyVBynemkTIhGs3ozTwvO7g8y34 fb24TVxnJfsdDjpLs0VM4zKDK8pDICkNMo5u2N3F2eVZGn+lCI0Vp1zDrB+EmA68DvtW 5Y7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:from:cc:content-transfer-encoding:mime-version:message-id:date :subject:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=p2M/qvXY4aKxeNNCaonXV2+iQxI4fghjZqtnhUD9h+Y=; b=y8vHMYjk7FSWAQt8HF3OeLFH2qAgpBoUHoObd6d87aPb1OYBXiK0lruyIgZzT9D0YV CeDSjpABW6aiVMuea76uREtJ6HLKEXTzRUWC6zgD8PJtSPK5dor/CQOL1/0BtiOh5xLU Z7NNXKceNDXz6zxu4xi62QN0r9cgHojVuVksXcZ1toKJ4O3OTX7hiHwCxhKnzHQUptXv YbOsNmEWfEO0ZyHfyC7Trz4neXi/4EGAC6wgMtQKtvEKz4liLPZnTPY9YVWKmH4W/Hk4 FlRrycZCp4lFcdn1kZnheLBbjVRbLTy8MEO/fNzTDGJaHfCmGK6iYm45mwEcPKX0YW7L vsUA== X-Gm-Message-State: ACrzQf189It2J366DbLS4px7KMBHqNrFOFGvT04hxBx6mbfnSbKSP8+C BjHJRXaSeGnKKOy6RmHQU2BoDg== X-Google-Smtp-Source: AMsMyM5ye1zKdtqjG7OXJTM074g58Rbrv293QIbVlI4J0vuZIl1BmcPlhkPrSb+i/GJ2QCY2CH+VzA== X-Received: by 2002:a65:464a:0:b0:434:883:ea21 with SMTP id k10-20020a65464a000000b004340883ea21mr6588546pgr.152.1665784641703; Fri, 14 Oct 2022 14:57:21 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id u5-20020a170902714500b00178323e689fsm2132469plm.171.2022.10.14.14.57.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Oct 2022 14:57:21 -0700 (PDT) Subject: [PATCH v2] RISC-V: Implement __clear_cache via __builtin___clear_cache Date: Fri, 14 Oct 2022 12:56:48 -0700 Message-Id: <20221014195648.8865-1-palmer@rivosinc.com> X-Mailer: git-send-email 2.38.0 MIME-Version: 1.0 From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org, Jim Wilson X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" We have had an implementation of __builtin___clear_cache since the beginning, but didn't have the cooresponding __clear_cache library routine implemented. This directly conflicts the GCC manual in a handful of places, which indicates that __clear_cache should work and that __builtin_clear_cache should function the same way as __clear_cache by ethier calling it or inlining the functionality. This patch simply implements __clear_cache via __builtin___clear_cache. This should be safe as we always have clear_cache insn so therefor __builtin___clear_cache will never fall back to calling __clear_cache. I'm not actually sure that silently implementing clear_cache as a NOP when there is no ISA defined mechanism for icache synchronization is the right way to go, but that's really a different discussion. This was reported as Bug 94136, which is a year old but was categorized as a documentation bug. I believe that categorization was incorrect: having an empty __clear_cache library routine is simply incorrect behavior, the fact that __builtin___clear_cache happens to be implemented as a libc call on Linux is just a red herring suggesting the documentation fix to point out the name difference. I view this new behavior as conforming to the existing documentation: we're just inlining the __clear_cache implementation, even if that implementation happens to be a call to a very similar looking libc routine. gcc/ChangeLog PR target/94136 * config/riscv/riscv.h (CLEAR_INSN_CACHE): New macro. --- Passes riscv-linux mulilib with no new failures. OK for trunk and backports to gcc-11, gcc-12? Changes since v1 <20210430045646.1508805-1-palmerdabbelt@google.com>: * Extra "_" as per Jim's comment. --- gcc/config/riscv/riscv.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h index acae68ebb2d..bb0dcb651d5 100644 --- a/gcc/config/riscv/riscv.h +++ b/gcc/config/riscv/riscv.h @@ -1080,4 +1080,9 @@ extern void riscv_remove_unneeded_save_restore_calls (void); #define REGISTER_TARGET_PRAGMAS() riscv_register_pragmas () +/* We always have a "clear_cache" insn, which means __builtin__clear_cache will + never emit a call to __clear_cache. */ +#undef CLEAR_INSN_CACHE +#define CLEAR_INSN_CACHE(BEG, END) __builtin___clear_cache((BEG), (END)); + #endif /* ! GCC_RISCV_H */