From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx08-006a4e02.pphosted.com (mx08-006a4e02.pphosted.com [143.55.148.243]) by sourceware.org (Postfix) with ESMTPS id 7486A3858C2B for ; Fri, 4 Nov 2022 09:53:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7486A3858C2B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=iram.es Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=iram.es Received: from pps.filterd (m0316695.ppops.net [127.0.0.1]) by mx08-006a4e02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2A49Dx6a032323; Fri, 4 Nov 2022 10:53:14 +0100 Received: from mta-out03.sim.rediris.es (mta-out03.sim.rediris.es [130.206.24.45]) by mx08-006a4e02.pphosted.com (PPS) with ESMTPS id 3kmpewejjn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Nov 2022 10:53:14 +0100 Received: from mta-out03.sim.rediris.es (localhost.localdomain [127.0.0.1]) by mta-out03.sim.rediris.es (Postfix) with ESMTPS id 52AC4304CF89; Fri, 4 Nov 2022 10:53:13 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta-out03.sim.rediris.es (Postfix) with ESMTP id 436723049C7D; Fri, 4 Nov 2022 10:53:13 +0100 (CET) X-Amavis-Modified: Mail body modified (using disclaimer) - mta-out03.sim.rediris.es Received: from mta-out03.sim.rediris.es ([127.0.0.1]) by localhost (mta-out03.sim.rediris.es [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PZUpLEgGsIZx; Fri, 4 Nov 2022 10:53:13 +0100 (CET) Received: from lt-gp.iram.es (haproxy02.sim.rediris.es [130.206.24.70]) by mta-out03.sim.rediris.es (Postfix) with ESMTPA id 0E69D302D6E2; Fri, 4 Nov 2022 10:53:12 +0100 (CET) Date: Fri, 4 Nov 2022 10:53:08 +0100 From: Gabriel Paubert To: Sebastian Huber Cc: GCC Development Subject: Re: -fprofile-update=atomic vs. 32-bit architectures Message-ID: References: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> Content-Transfer-Encoding: quoted-printable X-Proofpoint-GUID: BFOoEUmmw7BSIjhXURAKK6vej0pu5dEW X-Proofpoint-ORIG-GUID: BFOoEUmmw7BSIjhXURAKK6vej0pu5dEW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-04_06,2022-11-03_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbounddefault_notspam policy=outbounddefault score=0 malwarescore=0 adultscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 suspectscore=0 lowpriorityscore=0 impostorscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211040064 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_LOW,RDNS_DYNAMIC,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 Fri, Nov 04, 2022 at 09:27:34AM +0100, Sebastian Huber wrote: > Hello, >=20 > even recent 32-bit architectures such as RISC-V do not support 64-bit a= tomic > operations. Using -fprofile-update=3Datomic for the 32-bit RISC-V RV32= GC ISA > yields: >=20 > warning: target does not support atomic profile update, single mode is > selected >=20 > For multi-threaded applications it is quite important to use atomic cou= nter > increments to get valid coverage data. I think this fall back is not re= ally > good. Maybe we should consider using this approach from Jakub Jelinek f= or > 32-bit architectures lacking 64-bit atomic operations: >=20 > if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED)= =3D=3D > 0) > __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELA= XED); >=20 > https://urldefense.com/v3/__https://patchwork.ozlabs.org/project/gcc/pa= tch/19c4a81d-6ecd-8c6e-b641-e257c1959baf@suse.cz/*1447334__;Iw!!D9dNQwwGX= tA!QgLVk_W5VF39jGPn64zfvbJ4IiAGApjLqzW7UkLWWuFD6ya4AAega4z4_tu2YquarSyTIl= 7qLzWvIefVpXkLKsAaeeIU63MtmQU$ >=20 > Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally r= educe > 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 inv= alid > coverage data. If someone wants atomic updates, then the updates should= be > atomic even if this means to use a library 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 > if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED)= =3D=3D > 0) > __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELA= XED); >=20 > if 32-bit atomics are available. This assumes little-endian byte order. Cheers, Gabriel >=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 >=20 > Registergericht: Amtsgericht M=FCnchen > Registernummer: HRB 157899 > Vertretungsberechtigte Gesch=E4ftsf=FChrer: Peter Rasmussen, Thomas D=F6= rfler > Unsere Datenschutzerkl=E4rung finden Sie hier: > https://urldefense.com/v3/__https://embedded-brains.de/datenschutzerkla= erung/__;!!D9dNQwwGXtA!QgLVk_W5VF39jGPn64zfvbJ4IiAGApjLqzW7UkLWWuFD6ya4AA= ega4z4_tu2YquarSyTIl7qLzWvIefVpXkLKsAaeeIUo5lh3vs$