From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id DF7CD3846992 for ; Tue, 6 Dec 2022 16:09:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF7CD3846992 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-lf1-x12b.google.com with SMTP id x28so7096951lfn.6 for ; Tue, 06 Dec 2022 08:09:05 -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=+NtKH/i16FeUdaOnLv1Br4huPJOHNpCYjg3PqyYfOXg=; b=VuGlPPbmwqpNjsoGTNXfVWnuoc4oowvSK8TqTt03TxOAa+ybPk7tDIbrYf3h+Hvzqa EDBrskyPED6+bq1+ObLcOFJRTSDggdpv0C5goCpgs+of2n0Eu9FwyzJNvZiGFiwQqTPz NL1WVftPO8coG48Lj538POxxxSFM0nhTGYF8b69zc6Q7JrNsf0ZusRF3rMLaaHLE6EIg YK/dqsKGXo1Y9S0+ubblrgLLruPVdQPnqDFKtU8jEyJK7EHJ3jeNbHB+h82o0UT5ikAq g/7dLjxF0U1g8eTT1nZcpg+PA6v97OsRRFrZFxJY4H1xN8bOaGJDekWhULVi8xHfu0jS e9hA== 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=+NtKH/i16FeUdaOnLv1Br4huPJOHNpCYjg3PqyYfOXg=; b=o8+8ZPDeRDSUKs6e74sVtqkCXLjHtbiN7Yzf6JGUSr37cjRwOg+kfTcJG1F3Dufl5j jNwFhaWugAR6y8GvKqNFhYpTAcXhlLYj1g9akD2rcwF9yFI4lXqJj19mCg3P5L1JBH+v BLXklgGPDHSglNa9WaYPVyPFOKSJ9AoyrU970r+2qrRPeU+vK5wu8QPI7xziJ4Nwgt3a pOHoDDzsZTrk9rGdQxf1pQrFw6eZhbc1Pn/jhn/IAivD+abB6xcwFET4S00S9SbcVWU7 LzzftV8WuLiQ0+RF3nh9H1F6qBUssVbiYHE3p+7JeyWp7AtiqC8uRB6dsbGgYgAoNa7r ZrTQ== X-Gm-Message-State: ANoB5pmXlQnNVD3nSB6Dfoky0gj2Ed+Omf5HjHQvrmk1Y7OHWcZFWid3 hJZx71UYo6bwasC9nDK4qVTeh7/pnbukhNfQkPs= X-Google-Smtp-Source: AA0mqf6bVsgoNLFwRrtoL7SBSwdKBvB/xHzxTiTqRufKyRa7YAw0Pw01dcm+CHLwAArNKZe63ZlRKr8cz86ohsP2pnk= X-Received: by 2002:a05:6512:39d4:b0:4b3:b6db:8cb5 with SMTP id k20-20020a05651239d400b004b3b6db8cb5mr27769219lfu.599.1670342944070; Tue, 06 Dec 2022 08:09:04 -0800 (PST) MIME-Version: 1.0 References: <13ec35ee-19b2-536c-42d9-28efcd01df5b@embedded-brains.de> <582f9b96-47e9-6005-8d62-fd209f979848@embedded-brains.de> <8dfe2880-783c-d63e-2315-959455988294@embedded-brains.de> In-Reply-To: <8dfe2880-783c-d63e-2315-959455988294@embedded-brains.de> From: Richard Biener Date: Tue, 6 Dec 2022 17:08:51 +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.1 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, Dec 6, 2022 at 2:11 PM Sebastian Huber wrote: > > On 05/12/2022 08:44, Richard Biener wrote: > > On Mon, Dec 5, 2022 at 8:26 AM Sebastian Huber > > wrote: > >> On 08/11/2022 11:25, Richard Biener wrote: > >>>> 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. > >> Would it help to change the > >> > >> if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_REL= AXED) > >> =3D=3D 0) > >> __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, > >> __ATOMIC_RELAXED); > >> > >> into > >> > >> unsigned int v =3D __atomic_add_fetch_4 ((unsigned int *) &val, = 1, > >> __ATOMIC_RELAXED) > >> =3D=3D 0) > >> v =3D (unsigned int)(v =3D=3D 0); > >> __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, > >> __ATOMIC_RELAXED); > > that's supposed to add 'v' instead of 1? Possibly use uint32_t here > > (aka uint32_type_node). > > > >> to get rid of an inserted control flow? > > That for sure wouldn't require any changes to how the profile > > instrumentation works, > > so yes it would be simpler. > > Yes, this seems to work. After a bit of trial and error I ended up with > something in gimple_gen_edge_profiler() like this (endian support is > missing): > > else if (flag_profile_update =3D=3D PROFILE_UPDATE_SPLIT_ATOMIC) > { > tree addr =3D tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgen= o); > tree f =3D builtin_decl_explicit (BUILT_IN_ATOMIC_ADD_FETCH_4); > gcall *stmt1 =3D gimple_build_call (f, 3, addr, one, > build_int_cst (integer_type_node, > MEMMODEL_RELAXED)); > tree low =3D create_tmp_var (uint32_type_node); > gimple_call_set_lhs (stmt1, low); > tree is_zero =3D create_tmp_var (boolean_type_node); > gassign *stmt2 =3D gimple_build_assign (is_zero, EQ_EXPR, low, > build_zero_cst (uint32_type_n= ode)); > tree high_inc =3D create_tmp_var (uint32_type_node); > gassign *stmt3 =3D gimple_build_assign (high_inc, COND_EXPR, is_ze= ro, > build_one_cst (uint32_type_no= de), > build_zero_cst (uint32_type_n= ode)); > tree addr_high =3D create_tmp_var (TREE_TYPE (addr)); > gassign *stmt4 =3D gimple_build_assign (addr_high, addr); > gassign *stmt5 =3D gimple_build_assign (addr_high, POINTER_PLUS_EX= PR, > addr_high, > build_int_cst (size_type_node= , 4)); > gcall *stmt6 =3D gimple_build_call (f, 3, addr_high, high_inc, > build_int_cst (integer_type_node, > MEMMODEL_RELAXED))= ; > gsi_insert_on_edge (e, stmt1); > gsi_insert_on_edge (e, stmt2); > gsi_insert_on_edge (e, stmt3); > gsi_insert_on_edge (e, stmt4); > gsi_insert_on_edge (e, stmt5); > gsi_insert_on_edge (e, stmt6); > } > > It can be probably simplified. Likely. I'd use the gimple_build () API from gimple-fold.h which builds the expression(s) to a gimple_seq creating necessary temporaries on-the-fly and then insert that sequence on the edge. But even the above should work. The generated code: > > .type f, @function > f: > lui a4,%hi(__gcov0.f) > li a3,1 > addi a4,a4,%lo(__gcov0.f) > amoadd.w a5,a3,0(a4) > lui a4,%hi(__gcov0.f+4) > addi a5,a5,1 > seqz a5,a5 > addi a4,a4,%lo(__gcov0.f+4) > amoadd.w zero,a5,0(a4) > li a0,3 > ret > > looks good for this code: > > int f(void) > { > return 3; > } > > The loading of the high address could be probably optimized from > > lui a4,%hi(__gcov0.f+4) > addi a4,a4,%lo(__gcov0.f+4) > > to > > addi a4,a4,4 > > I wasn't able to figure out how to do this. I think that's something for the backend - we're not good CSEing parts of an "invariant" address and the above might be the form required when relocations are needed. 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/