From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id 86DA83858417; Wed, 7 Feb 2024 16:25:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 86DA83858417 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 86DA83858417 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.132.182.106 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707323152; cv=none; b=rcB3Mas+FQ4kOxMG9sGQebd4sc3m1xi4hkoeF0gLX60Laf1DGD1VsANaWVHuO7kR/ZRepMKGmMOUTgJg/nY5QK4ukn04wa1M7QWlpHstej7s7W1ms+ngxn+5/f0Uiksbn9ndxk3VL4q0U7nj4vCRB7qoYm5dpWrcTn/quSk9caw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707323152; c=relaxed/simple; bh=6yyeafDBZR70buTFs0DaBIoFExjgUK8qfJMtyaY3MnM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=mOJeNnpvfU93+St4sr2erZRafwOPFAGQBbFc01HBE/1HugG1KD0xB0P1HLAfuokAr819vDVtl5gd1aNExLlk3xrt95jTeZ0KiVwUzmMYQwsxDd6qIVh5fQXucStERrLe4pwkCkrSTcYe8ka9CSmFINSFTR5RNl++Ps8ycTbNpfQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0288072.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 417E0M61011985; Wed, 7 Feb 2024 17:25:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s= selector1; bh=YCkIdLuDuZzKHLhVTgPfoYNfDtgTkE8zfwjFomsQAyc=; b=5n KkM6C6BQAotZ/N8j1I6hwUyx8JLFnSFehef1V4dub5THxjB+dHfTlOY1jE4e1RoT BbFuTIXOcDLkh/CjxxEecaM4ZNfLtve99mMJywUNTmLfcz26DcJXn5AA5iN1tWPQ L2gb/lyWarEfXyMmK6aqhRqueFEYoe5PDvwKOxy36ruHbU5G6/P4UO0HRSoQBjT0 OhzblOGoDeorr4h9XDnA7uxmRmAPIvNUIlTn8JPY31dOwNTil05xVKgzG4UuV0m7 XyNtf/dhMTuX0ri3J2cW1/y0X3vLOEUOeQzDrbRrFTHMbOATAdISn3i9Ak2sSrvC 3Dn8vayLn/610Ueu91WA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3w1eyph5xn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2024 17:25:47 +0100 (CET) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B20C1100056; Wed, 7 Feb 2024 17:25:46 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id A5E3025D6C5; Wed, 7 Feb 2024 17:25:46 +0100 (CET) Received: from [10.74.18.1] (10.74.18.1) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 7 Feb 2024 17:25:46 +0100 Message-ID: <275f454b-537a-44d2-8aae-85e4484d9c52@foss.st.com> Date: Wed, 7 Feb 2024 17:25:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] libstdc++: optimize bit iterators assuming normalization [PR110807] Content-Language: en-US To: Jonathan Wakely , Alexandre Oliva CC: Jonathan Wakely , gcc-patches , libstdc++ , Yvan Roux References: From: Torbjorn SVENSSON In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.74.18.1] X-ClientProxiedBy: SHFCAS1NODE1.st.com (10.75.129.72) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-07_07,2024-02-07_01,2023-05-22_02 X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URI_HEX 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: Hi, Is it okay to backport e39b3e02c27bd771a07e385f9672ecf1a45ced77 to releases/gcc-13? Without this backport, I see this failure on arm-none-eabi: FAIL: 23_containers/vector/bool/110807.cc (test for excess errors) Kind regards, Torbjörn On 2023-11-09 02:22, Jonathan Wakely wrote: > > > On Thu, 9 Nov 2023, 01:17 Alexandre Oliva, > wrote: > > On Nov  8, 2023, Jonathan Wakely > wrote: > > > A single underscore prefix on __GLIBCXX_BUILTIN_ASSUME and > > __GLIBCXX_DISABLE_ASSUMPTIONS please. > > That's entirely gone now. > > >> +    do                                              \ > >> +      if (std::is_constant_evaluated ())    \ > >> +    static_assert(expr);                    \ > > > This can never be valid. > > *nod* > > > This already works fine in constant evaluation anyway. > > Yeah, that's what I figured. > > > But what's the null dereference for? > > The idea was to clearly trigger undefined behavior.  Maybe it wasn't > needed, it didn't occur to me that __builtin_unreachable() would be > enough.  I realize I was really trying to emulate attribute assume, even > without knowing it existed ;-) > > >> +#define __GLIBCXX_BUILTIN_ASSUME(expr)              \ > >> +    (void)(false && (expr)) > > > What's the point of this, just to verify that (expr) is contextually > > convertible to bool? > > I'd have phrased it as "avoid the case in which something compiles with > -O0 but not with -O", but yeah ;-) > > > We don't use the _p suffix for predicates in the library. > > Please use just _M_normalized or _M_is_normalized. > > ACK.  It's also gone now. > > > But do we even need this function? It's not used anywhere else, > can we > > just inline the condition into _M_assume_normalized() ? > > I had other uses for it in earlier versions of the patch, but it makes > no sense any more indeed. > > >> +    _GLIBCXX20_CONSTEXPR > >> +    void > >> +    _M_assume_normalized() const > > > I think this should use _GLIBCXX_ALWAYS_INLINE > > *nod*, thanks > > >> +    { > >> +      __GLIBCXX_BUILTIN_ASSUME (_M_normalized_p ()); > > > Is there even any benefit to this macro? > > I just thought it could have other uses, without being aware that the > entire concept was available as a statement attribute.  Funny, I'd even > searched for it among the existing attributes and builtins, but somehow > I managed to miss it.  Thanks for getting me back down that path. > > >        __attribute__((__assume__(_M_offset < > unsigned(_S_word_bit)))); > > That unfortunately doesn't work, because the assume lowering doesn't go > as far as dereferencing the implicit this and making an SSA_NAME out of > the loaded _M_offset, which we'd need to be able to optimize based on > it.  But that only took me a while to figure out and massage into > something that had the desired effect.  Now, maybe the above *should* > have that effect already, but unfortunately it doesn't. > > > Maybe even get rid of _M_assume_normalized() as a function and just > > put that attribute everywhere you currently use _M_assume_normalized. > > Because of the slight kludge required to make the attribute have the > desired effect (namely ensuring the _M_offset reference is evaluated), > I've retained it as an inline function. > > Here's what I'm retesting now.  WDYT? > > > ofst needs to be __ofst but OK for trunk with that change. > > We probably want this on the gcc-13 branch too, but let's give it some > time on trunk in case the assume attribute isn't quite ready for prime time.