From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) by sourceware.org (Postfix) with ESMTPS id B77F13858C2F for ; Tue, 8 Nov 2022 06:22:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B77F13858C2F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embedded-brains.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embedded-brains.de Received: from sslproxy04.your-server.de ([78.46.152.42]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1osHzx-000GJV-W2; Tue, 08 Nov 2022 07:22:14 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy04.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1osHzx-000LpM-Hm; Tue, 08 Nov 2022 07:22:13 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1445B480024; Tue, 8 Nov 2022 07:22:13 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id aHCUgu3mEmtn; Tue, 8 Nov 2022 07:22:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 6E1A24800E2; Tue, 8 Nov 2022 07:22:12 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gOGUfbXjF3AX; Tue, 8 Nov 2022 07:22:12 +0100 (CET) Received: from [192.168.96.159] (unknown [192.168.96.159]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 47B0C480024; Tue, 8 Nov 2022 07:22:12 +0100 (CET) Message-ID: <582f9b96-47e9-6005-8d62-fd209f979848@embedded-brains.de> Date: Tue, 8 Nov 2022 07:22:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: -fprofile-update=atomic vs. 32-bit architectures To: Richard Biener Cc: GCC Development References: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> Content-Language: en-US From: Sebastian Huber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.7/26713/Mon Nov 7 09:52:07 2022) X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,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 05.11.22 12:18, Richard Biener wrote: > On Fri, Nov 4, 2022 at 9:28 AM Sebastian Huber > wrote: >> Hello, >> >> even recent 32-bit architectures such as RISC-V do not support 64-bit >> atomic operations. Using -fprofile-update=3Datomic for the 32-bit RIS= C-V >> RV32GC ISA yields: >> >> warning: target does not support atomic profile update, single mode is >> selected >> >> For multi-threaded applications it is quite important to use atomic >> counter increments to get valid coverage data. I think this fall back = is >> not really good. Maybe we should consider using this approach from Jak= ub >> Jelinek for 32-bit architectures lacking 64-bit atomic operations: >> >> if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAX= ED) >> =3D=3D 0) >> __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, >> __ATOMIC_RELAXED); >> >> https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641= -e257c1959baf@suse.cz/#1447334 >> >> Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally >> reduce the gcov type size to 32 bits. I am not really sure if this was= a >> good idea. Longer running executables may observe counter overflows >> leading to invalid coverage data. If someone wants atomic updates, the= n >> the updates should be atomic even if this means to use a library >> implementation (libatomic). >> >> What about the following approach if -fprofile-update=3Datomic is give= n: >> >> 1. Use 64-bit atomics if available. >> >> 2. Use >> >> if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAX= ED) >> =3D=3D 0) >> __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, >> __ATOMIC_RELAXED); >> >> if 32-bit atomics are available. >> >> 3. Else use a library call (libatomic). > sounds good, though a library call would really be prohibitly expensive= ? I someone wants to profile a multi-threaded application and selects=20 -fprofile-update=3Datomic, then probably a correct result is preferred.=20 You still have the option to select -fprofile-update=3Dprefer-atomic. For 2. I have to modify: void gimple_gen_edge_profiler (int edgeno, edge e) { tree one; one =3D build_int_cst (gcov_type_node, 1); if (flag_profile_update =3D=3D PROFILE_UPDATE_ATOMIC) { /* __atomic_fetch_add (&counter, 1, MEMMODEL_RELAXED); */ tree addr =3D tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgen= o); tree f =3D builtin_decl_explicit (TYPE_PRECISION (gcov_type_node) = > 32 ? BUILT_IN_ATOMIC_FETCH_ADD_8: BUILT_IN_ATOMIC_FETCH_ADD_4); gcall *stmt =3D gimple_build_call (f, 3, addr, one, build_int_cst (integer_type_node, MEMMODEL_RELAXED)); gsi_insert_on_edge (e, stmt); } Is if (WORDS_BIG_ENDIAN) the right way to check for big/little endian? How do I get ((unsigned int *) &val) + 1 from tree addr? It would be great to have a code example for the construction of the "if=20 (f()) f();". --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/