From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id 57843385800A for ; Thu, 3 Dec 2020 10:38:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 57843385800A Received: by mail-ot1-x336.google.com with SMTP id t18so1303664otk.2 for ; Thu, 03 Dec 2020 02:38:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nW8REf45gKhmS+x6Cf/TL0ykEqOlDgex2YdK1XOfGn4=; b=sAFqVlE1iTi7erpOHt1ilhy/Ls++fIuiQT27DHW3BASIxQ04xQ/67JseQENNW1uNMu tYJX64t84cN4nDU5485i21gj/FmwARIgddd5VLtgmyf7CXHimoItkgdY3toQwZAPi+hd joUOoCTyqdFT4Z6DEee11B5oQwHS3aIQPJGoCt2HCX3eJzlw29HabOSw+ZsjG1mc26sb vBfO+PM5njzC9QbgsEeKjU1QeMuM/PEosU1lRdBa+KGdHR9xHldx1B1xLR4oVVLzcSWC f+fMmJCiEb7jBWfoFjzd2UpdeN2ZD2TyAzxwcKi3CR1WiV92t1pHgMdmNPfBWPoxOi4O zGcA== X-Gm-Message-State: AOAM532i0lmZ+w33sDA9QQaug0BDgkpXOXUdZV9y4JNaCt/VpPqRn5Hc Glh6qB2TgLx1plbysxen0txgE2tArowwiD05vVrtGw== X-Google-Smtp-Source: ABdhPJzDipMLaLu5XdFDa4lml9ZcdiDEGKngAXJf4rh4NjFFaNi25BFO3/9QO52blEXCM9F3RAtIKgh2DLGasjOrE/U= X-Received: by 2002:a9d:2ac5:: with SMTP id e63mr1554551otb.218.1606991908615; Thu, 03 Dec 2020 02:38:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christophe Lyon Date: Thu, 3 Dec 2020 11:38:18 +0100 Message-ID: Subject: Re: introduce overridable clear_cache emitter To: Jeff Law Cc: Alexandre Oliva , gcc Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: , X-List-Received-Date: Thu, 03 Dec 2020 10:38:31 -0000 Hi Alexandre, On Wed, 2 Dec 2020 at 19:23, Jeff Law via Gcc-patches wrote: > > > > On 11/10/20 7:35 PM, Alexandre Oliva wrote: > > This patch introduces maybe_emit_call_builtin___clear_cache for the > > builtin expander machinery and the trampoline initializers to use to > > clear the instruction cache, removing a source of inconsistencies and > > subtle errors in low-level machinery. > > > > I've adjusted all trampoline_init implementations that used to issue > > explicit calls to __clear_cache or similar to use this new primitive. > > > > > > Specifically on vxworks targets, we needed to drop the __clear_cache > > symbol in libgcc, for reasons related with linking that I didn't need > > to understand, and we wanted to call cacheTextUpdate directly, despite > > the different calling conventions: the second argument is a length > > rather than the end address. > > > > So I introduced a target hook to enable target OS-level overriding of > > builtin __clear_cache call emission, retaining nearly (*) the same > > logic to govern the decision on whether to emit a call (or nothing, or > > a machine-dependent insn) but enabling a call to a target > > system-defined function with different calling conventions to be > > issued, without having to modify .md files of the various > > architectures supported by the target system to introduce or modify > > clear_cache insns. > > > > (*) I write "nearly" mainly because, when not optimizing, we'd issue a > > call regardless, but since the call may now be overridden, I added it > > to the set of builtins that are not directly turned into calls when > > not optimizing, following the normal expansion path instead. It > > wouldn't be hard to skip the emission of cache-clearing insns when not > > optimizing, but it didn't seem very important, especially for the new > > uses from trampoline init. > > > > Another difference that might be relevant is that now we expand > > the begin and end arguments unconditionally. This might make a > > difference if they have side effects. That's prettty much impossible > > at expand time, but I thought I'd mention it. > > > > > > I have NOT modified targets that did not issue cache-clearing calls in > > trampoline init to use the new clear_cache-calling infrastructure even > > if it would expand to nothing. I have considered doing so, to have > > __builtin___clear_cache and trampoline init call cacheTextUpdate on > > all vxworks targets, but decided not to, since on targets that don't > > do any cache clearing, cacheTextUpdate ought to be a no-op, even > > though rs6000 seems to use icbi and dcbf instructions in the function > > called to initialize a trampoline, but AFAICT not in the __clear_cache > > builtin. Hopefully target maintainers will have a look and take > > advantage of this new piece of infrastructure to remove such > > (apparent?) inconsistencies. Not rs6000 and other that call asm-coded > > trampoline setup instructions, for sure, but they might wish to > > introduce a CLEAR_INSN_CACHE macro or a clear_cache expander if they > > don't have one. > > > > > > This was regstrapped on x86_64-linux-gnu, and a trivial backport was > > tested on multiple vxworks targets. Ok to install? > > > > > > for gcc/ChangeLog > > > > * builtins.c (default_emit_call_builtin___clear_cache): New. > > (maybe_emit_call_builtin___clear_cache): New. > > (expand_builtin___clear_cache): Split into the above. > > (expand_builtin): Do not issue clear_cache call any more. > > * builtins.h (maybe_emit_call_builtin___clear_cache): Declare. > > * config/aarch64/aarch64.c (aarch64_trampoline_init): Use > > maybe_emit_call_builtin___clear_cache. > > * config/arc/arc.c (arc_trampoline_init): Likewise. > > * config/arm/arm.c (arm_trampoline_init): Likewise. > > * config/c6x/c6x.c (c6x_initialize_trampoline): Likewise. > > * config/csky/csky.c (csky_trampoline_init): Likewise. > > * config/m68k/linux.h (FInALIZE_TRAMPOLINE): Likewise. > > * config/tilegx/tilegx.c (tilegx_trampoline_init): Likewise. > > * config/tilepro/tilepro.c (tilepro_trampoline_init): Ditto. > > * config/vxworks.c: Include rtl.h, memmodel.h, and optabs.h. > > (vxworks_emit_call_builtin___clear_cache): New. > > * config/vxworks.h (CLEAR_INSN_CACHE): Drop. > > (TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE): Define. > > * target.def (trampoline_init): In the documentation, refer to > > maybe_emit_call_builtin___clear_cache. > > (emit_call_builtin___clear_cache): New. > > * doc/tm.texi.in: Add new hook point. > > (CLEAR_CACHE_INSN): Remove duplicate 'both'. > > * doc/tm.texi: Rebuilt. > > * targhooks.h (default_meit_call_builtin___clear_cache): > > Declare. > > * tree.h (BUILTIN_ASM_NAME_PTR): New. > > > > for libgcc/ChangeLog > > > > * config/t-vxworks (LIB2ADD): Drop. > > * config/t-vxworks7 (LIB2ADD): Likewise. > > * config/vxcache.c: Remove. This patches causes a lot of regressions in fortran on arm and aarch64, see: https://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/r11-5692-gc05ece92c6153289fd6055e31e791e59b8ac4121/report-build-info.html (click on the red REGRESSED to get a summary of the regressions, and "log" next to it to download the corresponding gfortran.log if you need it) Can you check/fix them? Thanks Christophe > OK > jeff >