From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 0F9EE3858C62 for ; Fri, 14 Oct 2022 21:59:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F9EE3858C62 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-pl1-x632.google.com with SMTP id f23so5935395plr.6 for ; Fri, 14 Oct 2022 14:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=to:from:content-transfer-encoding:mime-version:message-id :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=UY1gOpw+SO7LBhqY2OZmTv39z8NeEMXsnqZ7Ege/Vk4=; b=PC2imN7S/N/jmQGXrah+K0+dLaR0xrYU4gsaVgijKm0tonMtvIuG5NxHR4iGuRvCgk cCruTP/teuXRIR2KrhPiR6SdHinaHoLDL40lo+NBab4xem8oRoRyKD8NgHrJ2KTeD0s7 IBhxdbpqR8gMriroFxWGz5V+tIRNgh8K/bnpOVQ6+uOyPaB7QouTF8tJaySNir07LdGm aUH7CZ/cQIaqMmTF5I4Xg9xkmPfrb3TmPX5yvE832hBMkJ/DTrRTN0ttGLbkbHV5MEqD r97OGsNaS7xhin0a+LpV7AM6O2rqyZ/ErssQQYDUTmxQHvvMwcG0yj8KRmtUjcWzXHjg NzHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:from:content-transfer-encoding:mime-version:message-id :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UY1gOpw+SO7LBhqY2OZmTv39z8NeEMXsnqZ7Ege/Vk4=; b=7KkKc8WP0tttiOOMoFQthkO74jcs2uOxaxP+EnxH6ONN0YrWhdI6A06oC780FCsTQs gVot+sXkdW2TmUX3/tgHRNpH1FWflzRPKAEgH+pD4SSZ1Bz3fkHETOE632qzWNS8tQFB 0RFIbuMiHowAq6b3/HTWZlkEN+TDto1m1i/15jdSrfn4QGoyQBwNv0uH2o3gA0vDEr/k Nmxy4WKBhpFDEUNLsPahn2bER6KueYQULOLpHleeHehZCIRObVQP1tT+y8RdHYq72uwl /J/RKulff+JdwO+0P4x+YUaT7/h9TUhKMXCbMCdytBaFVlaw7Z6gHZva4/u6h8PwNema fz9g== X-Gm-Message-State: ACrzQf28jjOSaLUekVCJrJhvKjp4BWRvPuU+FI4bkpW8EUssk0+OWoY9 TS95qu66uwJNaBXt7uHHm4kwnrUyAnC2w92l X-Google-Smtp-Source: AMsMyM4gqCRWX60myoJkZ+VJqh9ieO2QDjSQQZ+lW//0gNxpk+EjmijbrMivUAWPTmseIVIN4UarHA== X-Received: by 2002:a17:903:1c6:b0:185:47ce:f4f0 with SMTP id e6-20020a17090301c600b0018547cef4f0mr1369497plh.132.1665784780729; Fri, 14 Oct 2022 14:59:40 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id w29-20020aa7955d000000b0056274716016sm2208502pfq.47.2022.10.14.14.59.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Oct 2022 14:59:40 -0700 (PDT) Date: Fri, 14 Oct 2022 14:59:40 -0700 (PDT) X-Google-Original-Date: Fri, 14 Oct 2022 14:59:29 PDT (-0700) Subject: Re: [PATCH v2] RISC-V: Implement __clear_cache via __builtin___clear_cache In-Reply-To: <20221014195648.8865-1-palmer@rivosinc.com> Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 List-Id: On Fri, 14 Oct 2022 12:56:48 PDT (-0700), Palmer Dabbelt wrote: > 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 Oops, accidentally hit send before checking the test results. There's a bunch of failures, not sure if they're new though as I was trying to bisect them down and have a dirty tree. This might take a few minutes... > 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 */