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 >
