On Mon, Aug 9, 2021 at 2:03 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>
>
>
> On 09/08/2021 13:27, Richard Biener wrote:
> >>> Can you not implement 64bit atomic support for 32bit SPARC somehow?
> >> The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction
> >> (gcc/config/sparc/sync.md). I don't know how you could implement a
> >> 64-bit atomic support using this without spin locks (this is how
> >> libatomic support for RTEMS works).
> > I see. Note the above get_gcov_type_could_ use a separate target macro
> > instead of LONG_LONG_TYPE_SIZE (GCOV_TYPE_SIZE?), that
> > way targets could opt to use a smaller counter.
>
> Ok, something like this?
Yeah, plus in defaults.h do
#ifndef GCOV_TYPE_SIZE
#define GCOV_TYPE_SIZE (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32)
#endif
and then ...
> diff --git a/gcc/config/sparc/rtemself.h b/gcc/config/sparc/rtemself.h
> index fa972af640cc..ac4f70c48c43 100644
> --- a/gcc/config/sparc/rtemself.h
> +++ b/gcc/config/sparc/rtemself.h
> @@ -40,3 +40,5 @@
>
> /* Use the default */
> #undef LINK_GCC_C_SEQUENCE_SPEC
> +
> +#define GCOV_TYPE_SIZE 32
> diff --git a/gcc/coverage.c b/gcc/coverage.c
> index ac9a9fdad228..51297665e7f4 100644
> --- a/gcc/coverage.c
> +++ b/gcc/coverage.c
> @@ -146,7 +146,7 @@ tree
> get_gcov_type (void)
> {
> scalar_int_mode mode
> - = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
> + = smallest_int_mode_for_size (GCOV_TYPE_SIZE > 32 ? 64 : 32);
just use
smallest_int_mode_for_size (GCOV_TYPE_SIZE);
> return lang_hooks.types.type_for_mode (mode, false);
> }
>
> diff --git a/gcc/tree-profile.c b/gcc/tree-profile.c
> index 5a74cc96e132..b7f3f445d05b 100644
> --- a/gcc/tree-profile.c
> +++ b/gcc/tree-profile.c
> @@ -250,7 +250,7 @@ gimple_gen_edge_profiler (int edgeno, edge e)
> {
> /* __atomic_fetch_add (&counter, 1, MEMMODEL_RELAXED); */
> tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
> - tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
> + tree f = builtin_decl_explicit (GCOV_TYPE_SIZE > 32
> ? BUILT_IN_ATOMIC_FETCH_ADD_8:
> BUILT_IN_ATOMIC_FETCH_ADD_4);
I think those uses should look at the actual gcov_type_node, not at the
target macro again. So TYPE_PRECISION (gcov_type_node) > 32.
> gcall *stmt = gimple_build_call (f, 3, addr, one,
> @@ -525,7 +525,7 @@ gimple_gen_time_profiler (unsigned tag)
> tree_time_profiler_counter);
> gassign *assign = gimple_build_assign (ptr, NOP_EXPR, addr);
> gsi_insert_before (&gsi, assign, GSI_NEW_STMT);
> - tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
> + tree f = builtin_decl_explicit (GCOV_TYPE_SIZE > 32
> ? BUILT_IN_ATOMIC_ADD_FETCH_8:
> BUILT_IN_ATOMIC_ADD_FETCH_4);
> gcall *stmt = gimple_build_call (f, 3, ptr, one,
>
> >
> > Note that it isn't currently feasible to for example use a 32bit gcov type
> > with =atomic but 64bit with =single since the "ABI" of the gcov data isn't
> > self-descriptive in this aspect. But it should be possible to record the
> > counter size in the meta-data and keep the on-disk format use "big"
> > counters in theory.
>
> The on-disk format shouldn't be an issue since we have:
>
> /* Dump the COUNTER using the DUMP handler called with ARG. */
>
> static inline void
> dump_counter (gcov_type counter,
> void (*dump_fn) (const void *, unsigned, void *),
> void *arg)
> {
> dump_unsigned ((gcov_unsigned_t)counter, dump_fn, arg);
>
> if (sizeof (counter) > sizeof (gcov_unsigned_t))
> dump_unsigned ((gcov_unsigned_t)(counter >> 32), dump_fn, arg);
> else
> dump_unsigned (0, dump_fn, arg);
> }
I think that's debugging, relevant is probably
gcov-io.c:gcov_read_counter? But I'm not too familiar with how the
bits of the gcov infrastructure play together. gcov-io.h documents
the IO format to some extent. It looks like there 'gcov_type' is
hard-wired to 64bits?
> >
> > But I guess using 32bit counters on sparc-rtems might be the way to
> > go ...
>
> Yes, you somehow just have to make sure that your test programs don't
> overflow the counters.
Right - thus in principle it would be "nice" to allow to alter this with
a command-line switch (even per TU in case 64bit is slow).
Richard.
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
