Re: introduce overridable clear_cache emitter

[Christophe Lyon <christophe.lyon@linaro.org>]

Hi Alexandre,

On Wed, 2 Dec 2020 at 19:23, Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> 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
>