From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id EA04E3858C62 for ; Tue, 8 Nov 2022 10:26:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EA04E3858C62 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-ej1-x62f.google.com with SMTP id kt23so37306192ejc.7 for ; Tue, 08 Nov 2022 02:26:10 -0800 (PST) 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=kQf+uot2ajhDWUMT2D27/BKGOAjvWA3b4bxaDoXdeRc=; b=BUeMtA3l8z9uB+l+D2p1uwiMNR0VHZvEv9jyingK7lqu3+7/GlP/ke1Zl2hVzr/GVy ebn/TNBgyJSEnXjXioZkigm2uFaJxFOrOPKgnPCJqe1e+6tm2T3dot8T1AigDdb4LdjD M8vdkdgvBrc5MivlaRgUDiXL9e1tS50uAolGtsxNIIk01Rs01cekW0quJ1eDCHgppnpX 5/6CPz0xZYiKSYO6nSNvOPxHLsF1X/DEzSbjJjUrA1zhOB/FdUSoiBXUPLNOUfbPBOrD LYKe4Yec00xkEdjtqotbqPUL7+uHFhk37i/qCLILIPpPuoINv3fgGNMZu1m7KPPhTBuM mD6w== 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=kQf+uot2ajhDWUMT2D27/BKGOAjvWA3b4bxaDoXdeRc=; b=lYK2pGeeMJLRTwEtfS9pe/ExxVMeKAqolu51YgcSuBBJcLEs2dsJOJqIHt26zIQSqG Ugve8Bg+RYozH2npjxxQxYIvWQ8W3Ygb80X1gj/+yzgnZpjVyvE2Mp7j1mjOesaMGJ0e OcUvfzGDevbWo8b3TU7+r3vkdB59kWG+KR9ymg378Jr480ez6hrscQW9aBKG9QgOi5MH OE8mXrZc0qVNiq0JiLG9d6qHDpaD3ud9cNpvY5ApzUFSSgpKDcPA6ZpkCUL1dTFrqWjB Zk/AquRUJTnOiKDHSzSIPRGUbioICimscBVpdN7ERDB+SdnpwFP4C4cfwNMALYsV0YaO iY+Q== X-Gm-Message-State: ACrzQf1dm5yuP344uFLyzSOB5g8yTJecOEHzyFsDmQ2H1VnuDJMt1EXk EsDCqDk2BliwW1qPSaH1k+itTgJxngELkX4Sct0= X-Google-Smtp-Source: AMsMyM73bUSiCiN6NW4/IzXI28CYuPWFssiI/k9bgWjUY8A3Cqmqn7WTWkbTBRIonxpuu0UBLG8lJD0bVGbLw/upbsw= X-Received: by 2002:a17:907:2c68:b0:7ad:8ba7:664a with SMTP id ib8-20020a1709072c6800b007ad8ba7664amr52549332ejc.488.1667903169695; Tue, 08 Nov 2022 02:26:09 -0800 (PST) MIME-Version: 1.0 References: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> <582f9b96-47e9-6005-8d62-fd209f979848@embedded-brains.de> In-Reply-To: <582f9b96-47e9-6005-8d62-fd209f979848@embedded-brains.de> From: Richard Biener Date: Tue, 8 Nov 2022 11:25:55 +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=-2.2 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 Tue, Nov 8, 2022 at 7:22 AM Sebastian Huber wrote: > > 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 > -fprofile-update=3Datomic, then probably a correct result is preferred. > 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? Yes. > 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 > (f()) f();". I think for the function above we need to emit __atomic_fetch_add_8, not the emulated form because we cannot insert the required control flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be lowered after the instrumentation took place. There's currently no helper to create a diamond so the canonical way is to create a GIMPLE_COND, split the block after this stmt, split the outgoing edge and then redirect edges to form a half-diamond. move_sese_in_condition has most of that CFG manipulation (but it performs sth different) Richard. > -- > 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/