From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 1EB673858C2F for ; Thu, 8 Jun 2023 09:06:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1EB673858C2F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686215159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ONErmicuJjuhmJRW0FQZ85JRIdETewjUSO+Fr4l7nvk=; b=KakJjpmRY+D7UVBJ/FlJNc48UXKx/RUn5fPyH7GiebsniIDjICwg79y/n5MBJDcNBfL7Z8 ggHnYgBoVmeJ4VJ0EoalHCi639DqE2M/+MFC/5ntmR+8NQrcVuKrJmdfFhHxHjsmqkyTVF QmqHIqAEm49SF76alpF0R5W9XMDEzPs= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-383-rQ4GIDE0OMmN_Ti1_BTcJQ-1; Thu, 08 Jun 2023 05:05:57 -0400 X-MC-Unique: rQ4GIDE0OMmN_Ti1_BTcJQ-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2b1c9bb99a9so1492551fa.3 for ; Thu, 08 Jun 2023 02:05:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686215156; x=1688807156; 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=ONErmicuJjuhmJRW0FQZ85JRIdETewjUSO+Fr4l7nvk=; b=QGHu6Nq3mw5MMsfH1j6OqH3u7pCzmGbpCZrAz2Q7Yoy/Dp06EF30tsPtnreZLI4xwu YE9tpfX2qDv2566HSyt9v1rt8WZHGpkz5z9nB++WM6PL3WtX+0NfvnjBc+wBmzJA50+c YCzkKIVSguDTksmT9QC51qNgkcDoayE5j3l1FfdBUyGPX8yxX4oXHq2f3L7uGNPuz0Ia Lw1KDA6fVK/UdbCWRhW4ajDHxxtnzkq6820hI1cWPatrOcTMWJJV15oDGh7nJ3K0Fb7A xBsPOBexfA1WNvDdqi4Rj8rmzwSV6CRZ2QbTKLITeV0jLNCqxvWJ3aL5yKvSziFJUAxP zPhA== X-Gm-Message-State: AC+VfDyf1gP9HLYnzE6dn5rGs/KcFT+hRanViOWnAtsYSuXXrVGVQXLG 6LjSpa/brM03iRuUQ1T4y6TL22L+aN7kF+prUZBD7Sr4VchBNqFyEdWj4zEeH3w4ziBbynn2HN8 x89dUa1aoF62op40a/SgZXyNN+wXYC0vzlQ== X-Received: by 2002:a19:f701:0:b0:4f6:2dbd:1e23 with SMTP id z1-20020a19f701000000b004f62dbd1e23mr3371032lfe.29.1686215155917; Thu, 08 Jun 2023 02:05:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7p/BTHAcdxCRwql+8RanK6yE+7QSA415BKQHoIx/Qax4qSGh9lD8uAEr3GekCHeKZR3VC2uK4sDADdZOfOGQE= X-Received: by 2002:a19:f701:0:b0:4f6:2dbd:1e23 with SMTP id z1-20020a19f701000000b004f62dbd1e23mr3371021lfe.29.1686215155527; Thu, 08 Jun 2023 02:05:55 -0700 (PDT) MIME-Version: 1.0 References: <20230601150958.268109-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 8 Jun 2023 10:05:43 +0100 Message-ID: Subject: Re: [committed] libstdc++: Fix code size regressions in std::vector [PR110060] To: Maxim Kuvyrkov Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000005c428605fd9a8fec" X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000005c428605fd9a8fec Content-Type: text/plain; charset="UTF-8" On Thu, 8 Jun 2023 at 09:58, Maxim Kuvyrkov wrote: > Hi Jonathan, > > Interestingly, this increases code-size of -O3 code on aarch64-linux-gnu > on SPEC CPU2017's 641.leela_s benchmark [1]. > > In particular, FastBoard::get_nearby_enemies() grew from 1444 to 2212 > bytes. This seems like a corner-case; the rest of SPEC CPU2017 is, mostly, > neutral to this patch. Is this something you may be interested in > investigating? I'll be happy to assist. > I'd certainly like to avoid the regression, but I'm too dumb to understand most inlining bugs myself. > > Looking at assembly, one of the differences I see is that the "after" > version has calls to realloc_insert(), while "before" version seems to have > them inlined [2]. > > [1] > https://git.linaro.org/toolchain/ci/interesting-commits.git/tree/gcc/sha1/b7b255e77a271974479c34d1db3daafc04b920bc/tcwg_bmk-code_size-cpu2017fast/status.txt > > I find it annoying that adding `if (n < sz) __builtin_unreachable()` seems to affect the size estimates for the function, and so perturbs inlining decisions. That code shouldn't add any actual instructions, so shouldn't affect size estimates. I mentioned this in a meeting last week and Jason suggested checking whether using __builtin_assume has the same undesirable consequences, so I think I'll start by investigating that. > [2] 641.leela_s is non-GPL/non-BSD benchmark, and I'm not sure if I can > post its compiled and/or preprocessed code publicly. I assume RedHat has > SPEC CPU2017 license, and I can post details to you privately. > > Yes, I think I can get the benchmark code from Vlad. Thanks for bringing this to my attention. --0000000000005c428605fd9a8fec--