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 896763835555 for ; Wed, 7 Dec 2022 09:55:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 896763835555 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 sslproxy01.your-server.de ([78.46.139.224]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1p2r97-0003RQ-SX for gcc@gcc.gnu.org; Wed, 07 Dec 2022 10:55:21 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p2r97-000G4t-Po for gcc@gcc.gnu.org; Wed, 07 Dec 2022 10:55:21 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 7F69D480028 for ; Wed, 7 Dec 2022 10:55:21 +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 9Xo1WDIIkWlJ for ; Wed, 7 Dec 2022 10:55:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 22F1548018B for ; Wed, 7 Dec 2022 10:55:21 +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 AzXtQ-tU0iJs for ; Wed, 7 Dec 2022 10:55:21 +0100 (CET) Received: from [192.168.96.159] (unknown [192.168.96.159]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 0DAFC480028 for ; Wed, 7 Dec 2022 10:55:21 +0100 (CET) Message-ID: <500ffefc-0364-70f9-d41a-390a87492e48@embedded-brains.de> Date: Wed, 7 Dec 2022 10:55:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: -fprofile-update=atomic vs. 32-bit architectures Content-Language: en-US From: Sebastian Huber To: GCC Development References: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> In-Reply-To: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> 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/26743/Wed Dec 7 09:17:04 2022) X-Spam-Status: No, score=-5.4 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 04.11.22 09:27, Sebastian Huber wrote: > Hello, >=20 > even recent 32-bit architectures such as RISC-V do not support 64-bit=20 > atomic operations.=C2=A0 Using -fprofile-update=3Datomic for the 32-bit= RISC-V=20 > RV32GC ISA yields: >=20 > warning: target does not support atomic profile update, single mode is=20 > selected >=20 > For multi-threaded applications it is quite important to use atomic=20 > counter increments to get valid coverage data. I think this fall back i= s=20 > not really good. Maybe we should consider using this approach from Jaku= b=20 > Jelinek for 32-bit architectures lacking 64-bit atomic operations: >=20 > =C2=A0 if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RE= LAXED)=20 > =3D=3D 0) > =C2=A0=C2=A0=C2=A0 __atomic_fetch_add_4 (((unsigned int *) &val) + 1, = 1,=20 > __ATOMIC_RELAXED); >=20 > https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641-= e257c1959baf@suse.cz/#1447334 >=20 > Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally=20 > reduce the gcov type size to 32 bits. I am not really sure if this was = a=20 > good idea. Longer running executables may observe counter overflows=20 > leading to invalid coverage data. If someone wants atomic updates, then= =20 > the updates should be atomic even if this means to use a library=20 > implementation (libatomic). >=20 > What about the following approach if -fprofile-update=3Datomic is given= : >=20 > 1. Use 64-bit atomics if available. >=20 > 2. Use >=20 > =C2=A0 if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RE= LAXED)=20 > =3D=3D 0) > =C2=A0=C2=A0=C2=A0 __atomic_fetch_add_4 (((unsigned int *) &val) + 1, = 1,=20 > __ATOMIC_RELAXED); >=20 > if 32-bit atomics are available. This approach works fine for the edge counters in=20 gimple_gen_edge_profiler() because we don't have to read the counter=20 value. We just have to do an increment. In gimple_gen_time_profiler() we=20 have to do this: /* Emit: counters[0] =3D ++__gcov_time_profiler_counter. */ So here we have to do an atomic increment and fetch the value. This=20 doesn't work with the approach above. For example let thread A increment=20 the lower part from 0xfffffffe to 0xffffffff, then let thread B=20 increment the lower part from 0xffffffff to 0x0, then the higher part=20 from 0x7 to 0x8, then let thread A read 0x8. Thread A would then get=20 0x8_ffffffff instead of the correct 0x7_ffffffff. >=20 > 3. Else use a library call (libatomic). >=20 --=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/