From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 1A5183858416 for ; Sat, 5 Nov 2022 11:18:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A5183858416 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x534.google.com with SMTP id 21so11011017edv.3 for ; Sat, 05 Nov 2022 04:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cZoQG9vlIudHuJAbHlyCoRU2Pg5NUbNdiEpgUzMYcSA=; b=Tvctzf2alEmmPQ2GoCg/lA2vfwPYGhn3Qquq7dUkWa4qW0jqVqXgLGNA6ZOPiw+C+I 3K7CvddbDrI0+ax481x77JLO31Z7pUQd4Mfl/Is0cpxhfmaesIqLh8boI7qnYf0bf5qs 46+PgGwmr8cE3BEYT4IgKMbxCR4ik3OgXlSj8QLdDDnQ5yBDb610PZPxaifbIsFeWM7W TdULl1WO7Jdp5iu3IuOUkezXIynX6TsgMprgEWgNsDDhFGIODePVRD1H984FxfAv+WNc GPSlQYZCAFMf8btg0QhMR2AIw1oG5NyxigqXSakxLfTmn42feJD4NkOeeVlmAtOi7znG 14yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cZoQG9vlIudHuJAbHlyCoRU2Pg5NUbNdiEpgUzMYcSA=; b=pCEpc0gAhzeWUouQd9w/kKImxbilJH0VsIFNVxvXN1A3SHQzv7HGVkUEjcK/GmTdrO H+G/VbAZ/lNOsuRltRhpDXnLrcsggXoz84Vsg/V1QY9Lrgu5hGmzkdiuMCV97xRoNt3I 0k9yFkc3Ax9VsMtOn9xp8hdB8fWZD655cPfh9yJ7Oip4aO7ymgdXyYxTrQw2plK2nW+r k8nIbeG56dI3mlzCkIHI6WD0w8U7KjaHZ8Ro7HPh8l/JTOnsdiFfHahc7Wyx1jDJaZd4 b9Jz/oePAskWiPcTP4dRheWgCwqd14uW1GLg27mL+U7eIW1wdFXvY4zqfUvjAlo+WDg+ XKyQ== X-Gm-Message-State: ACrzQf2+/IwnRTdw5D+gnsoOCT5WjDqDhcsv+yZNQ9LpbZFqfdIQ/sYr ZyglZMg7wC0dbZbxvUDh3zJUQa2XO1EifMbf4sU9QpHK X-Google-Smtp-Source: AMsMyM6gUoyO+UMoLFV86tyXgnThxTXUxAk6zjw75OX0PdRpYVVUrytIdayFOkr61tt6FiJUMVGPMQInMzhWuWCoQXU= X-Received: by 2002:a05:6402:3457:b0:463:2017:ae64 with SMTP id l23-20020a056402345700b004632017ae64mr36183156edc.218.1667647105747; Sat, 05 Nov 2022 04:18:25 -0700 (PDT) MIME-Version: 1.0 References: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> In-Reply-To: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> From: Richard Biener Date: Sat, 5 Nov 2022 12:18:13 +0100 Message-ID: Subject: Re: -fprofile-update=atomic vs. 32-bit architectures To: Sebastian Huber Cc: GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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 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 RISC-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 Jakub > Jelinek for 32-bit architectures lacking 64-bit atomic operations: > > if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) > =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-e2= 57c1959baf@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, then > 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 given: > > 1. Use 64-bit atomics if available. > > 2. Use > > if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) > =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? > -- > 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/