From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 9DB0F3858D39 for ; Thu, 27 Jul 2023 15:14:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9DB0F3858D39 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-wr1-x429.google.com with SMTP id ffacd0b85a97d-317786befa2so1109110f8f.3 for ; Thu, 27 Jul 2023 08:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690470844; x=1691075644; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=q1VppAtg/WK+dcUybCcNFpbsGkXo1xwbRxTyVaDbjvE=; b=KbmQMQXK/q0JiKhX4tnJmj6iE9AtbfBn0z6TFXZiaGEqe/tw73BIMBEhV3zoyPEZt9 TjGX/Opjt7bBI76sj7AmOpNmdkFY/537pxwqqtUZ1u5ARrMBkU63V2QsIFWHUp5RXBsA 2iy17zj+zAx1S15FhFfYtOf+6vLsqVhEs7PbpIHYSzdm8RSuKIB57K+iuYPrKyZ2EhyV dsox46VhIgcLdolAYWCcSWoANJO337liVWxbsVMDPJEEqG2uhiZGcDIO9gZVHWDyNFGN VF6I3a4Faat7/z/nNhfNoNa+fiWrnNcS4VeL9+myM9O8kWHSUzrgzJ8NqVpDz7fccypD 8DKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690470844; x=1691075644; h=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=q1VppAtg/WK+dcUybCcNFpbsGkXo1xwbRxTyVaDbjvE=; b=cimaIFPL5mzkPxu9b31+op15GbXg1rCHxWfGkaok4pc7oYMLRLJZxCUi1FWGgTPbHk ZXkoeON80iigpZf8AiK5A3TIeAPCH6Lrk01Q8MYvljQtMUru0zD9KiGRzjZCyWeCbP7/ SgyJNatd/u1PFr7gaZPWw9pscLTLj+www/1n4WAAYrWd+4LnGV+DWRb6G4F5A9GiL98s Cub49vti3TcITP3jcVoMc3NHCfD+5YKQlkRpq6FxBabYizR8U61Ps82a6nzKBq1CCNmv An4kBJRSlNYc6HJuzHLPCCeqX63pZ+RSksvBWaqPXmZ6xQMyGvmEBL5mc8TKaWagD1NL qiHg== X-Gm-Message-State: ABy/qLY/1hy3J22mJ7hrImkdw9BdC+wW6AKaA0B6FCre9/3Ff8PWI3/+ aypLGUkZNH0lB1cVaj8JsOvANhvDVwSEwqRcgPs= X-Google-Smtp-Source: APBJJlHc4KwkldwYP82J6X/J+otxczjJfR6j9o7D2Qw4t791profCg8LdpOOVFFc3B2UaS0CyCt1ICjKoT5TfMUinKE= X-Received: by 2002:adf:f7c5:0:b0:30f:d218:584a with SMTP id a5-20020adff7c5000000b0030fd218584amr2001852wrq.23.1690470843587; Thu, 27 Jul 2023 08:14:03 -0700 (PDT) MIME-Version: 1.0 References: <20230726160524.1955013-1-skpgkp2@gmail.com> <874jlp4vlz.fsf@oldenburg3.str.redhat.com> <8f7d6d53-5157-0b3a-b8ad-1afd940cae6f@ispras.ru> <87r0ot367s.fsf@oldenburg3.str.redhat.com> <492f2c2c-1cb7-20ef-e4a3-4bdda76e5f9b@ispras.ru> In-Reply-To: <492f2c2c-1cb7-20ef-e4a3-4bdda76e5f9b@ispras.ru> From: Sunil Pandey Date: Thu, 27 Jul 2023 08:13:27 -0700 Message-ID: Subject: Re: [PATCH] x86_64: Optimize ffsll function code size. To: Alexander Monakov Cc: Florian Weimer , Noah Goldstein via Libc-alpha , Noah Goldstein , Richard Henderson , hjl.tools@gmail.com Content-Type: multipart/alternative; boundary="00000000000022a2df0601796a7e" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: --00000000000022a2df0601796a7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 27, 2023 at 7:00=E2=80=AFAM Alexander Monakov wrote: > > On Thu, 27 Jul 2023, Florian Weimer via Libc-alpha wrote: > > > * Alexander Monakov: > > > > > On Thu, 27 Jul 2023, Florian Weimer via Libc-alpha wrote: > > > > > >> * Noah Goldstein via Libc-alpha: > > >> > > >> > Likewise for the string/memory library.... > > >> > Why not just update it w.o cmov? Just seems like a waste not to > > >> > address it while we're at it. > > >> > > >> Given that it violates the spec, doing it in an inline function seems > > >> kind of risky. > > > > > > Sorry, what inline function? The function seems to modify an > implementation > > > in ffsll.c, nothing else. > > > > Yeah, sorry, I was confused. There's a GCC built-in, right? So the > > glibc implementation probably isn't that important on x86. > > Yep. The built-in gets expanded even at -Os, so it's quite unusual that > Glibc's > implementation get called. I see the following possibilities: > > * at -O0 (but then performance doesn't matter, presumably) > * with -fno-builtin > * when called via a function pointer > > Sunil, could you clear this up, please? > This issue only matters if ffsll functionality is implemented in a function(size > 16 byte) and the function is not inlined (doesn't matter whether it's implemented in C or assembly). By default the function entry point gets aligned to the 16 byte boundary, so the following layout are all valid. 64 byte aligned: No issue as 17 byte function will not cause another cache line load. 48 byte aligned: ~20% regression as 17 byte function will trigger another cache line load. 32 byte aligned: No issue as 17 byte function will not cause another cache line load. 16 byte aligned: No issue as 17 byte function will not cause another cache line load. Ffsll is one of the benchmark tests in the phoronix test suite, not sure how much it matters to the application. Lots of people involved in phoronix benchmark testing/tracking and this kind of random perf behavior wastes their time. Again I'm not against GCC, but if this function exists in glibc, I don't see any harm in fixing it. > > Alexander > --00000000000022a2df0601796a7e--