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.133.124]) by sourceware.org (Postfix) with ESMTPS id 332703858D32 for ; Thu, 10 Aug 2023 21:01:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 332703858D32 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=1691701283; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kCMjFTGqc/0Zzwt/14aH3dn+e+a4fGSWS0jhybWpbzk=; b=aj7EDkQH3vTA1iLcHGdehjr4en1u1M9cgPOfbWB7x2vqiTn0HZRlxnl4K/hxCwscq4mavX bmcqgr7F9q5egaxDt7kzZfxAxTpgryvMwIHeZzngtMWQpjxeq5MyF29RAw1ygWD5scy1gt bccrCapZQ0M+eonFa6eNSnF+7JMRQp8= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-450-nx79oEwHO5eUZyhctEGexA-1; Thu, 10 Aug 2023 17:01:22 -0400 X-MC-Unique: nx79oEwHO5eUZyhctEGexA-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-63d41d15574so17775376d6.0 for ; Thu, 10 Aug 2023 14:01:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691701281; x=1692306081; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kCMjFTGqc/0Zzwt/14aH3dn+e+a4fGSWS0jhybWpbzk=; b=V2YG77JKkA5KECAgnlrUvEHZvDrLS+wX7fyAqTF1/leE4cIO2/SvXOqZhOIYumDxCJ xvNSPWQgQQCzzs8ksppagXFMQ8FbRz7Um56ntu6JbnM19N5XcfTeElV11D4Y9VTYen05 Y0oLNKXSlPZ/O9vdDnSWrSaUjucHEf8iCWiw2+mjujFvyviNXHHv3oqfafxtMD0hFoOZ GDQbWDdN2lCvEYAbYN6LGT/mpnKc8AEYgQeeXM+i5WEa/L/4GFdmtxrzbMFgWbTVDNDj KRb1Rvb+aTQ33noXNRM4cufLU7ZQOj5JzptrJSI/hDE7XeQW+3P05tXsaBaq50kZCwIJ Tinw== X-Gm-Message-State: AOJu0YzRcDQY0dWAg0ffPG5Y2iek3fohrOfOXzSELL+04BpAqcYyeJxE CBxQQNJE5aWOzTWdKqwP7n1wHWL4GWFAr+6oDDr8oGdi+EZ6KPP65QqPUKxfs/JCkY8ZyfrCsMj llGpi62roLlsMY2EKNH/wlYuLfA== X-Received: by 2002:ad4:4691:0:b0:63d:657:4582 with SMTP id pl17-20020ad44691000000b0063d06574582mr3209327qvb.11.1691701281444; Thu, 10 Aug 2023 14:01:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE36wULJotGg9ZndSqxVRhQCpK6JKxIkd8dIAmCJDaRhaksPWrGKxlPmkGL+TG6/RJwwjRDXQ== X-Received: by 2002:ad4:4691:0:b0:63d:657:4582 with SMTP id pl17-20020ad44691000000b0063d06574582mr3209311qvb.11.1691701281159; Thu, 10 Aug 2023 14:01:21 -0700 (PDT) Received: from [192.168.1.108] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id p6-20020a0ce186000000b00632266b569esm740070qvl.87.2023.08.10.14.01.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Aug 2023 14:01:20 -0700 (PDT) Message-ID: <5434e9ee-dc02-cd84-a19c-06f288a21356@redhat.com> Date: Thu, 10 Aug 2023 17:01:19 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [RFC PATCH v2] c++: extend cold, hot attributes to classes To: Javier Martinez , gcc-patches@gcc.gnu.org References: From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 8/10/23 14:06, Javier Martinez wrote: > > Thanks for the comments, Jason. > v2: + Fix formatting, remove unnecessarily warning. > > On Tue, Aug 8, 2023 at 10:28 PM Jason Merrill > wrote: > > Seems reasonable, but how do you expect this to be used? > We have large applications where some large classes are known to be used > only at startup. Marking every member function as cold is impractical so > we would mark those classes as cold. Sure, though I think of the cold attribute as being primarily to mark unlikely paths in otherwise hot code; is this a if (!initialized) do_initialization(); kind of situation? > > I think doing this here will miss lazily-declared special member > > functions; I wonder if you want to copy the attribute in grokclassfn > > instead? > I think they are being handled correctly with the current patch. > Considered the following program: > > class __attribute((cold)) Foo { > public: >     int m_x, m_y; >     auto operator<=>(const Foo&) const = default; > }; > > int main(void) { >     Foo a{1,1}; >     Foo b{1,2}; > >     std::set s; // OK >     s.insert(a);     // OK > >     std::cout << std::boolalpha >         << (a == b) << ' ' >         << (a != b) << ' ' >         << (a <  b) << ' ' >         << (a <= b) << ' ' >         << (a >  b) << ' ' >         << (a >= b) << ' ' >         << std::endl; > } > > Per the rules for any operator<=> overload, a defaulted <=> overload > will also allow the type to be compared with <, <=, >, and >=. If > operator<=> is defaulted and operator== is not declared at all, then > operator== is implicitly defaulted. > The GIMPLE dump shows: > > __attribute__((cold)) > > struct strong_ordering Foo::operator<=> (const struct Foo * const > this, const struct Foo & D.64195) > > __attribute__((cold)) > > bool Foo::operator== (const struct Foo * const this, const struct Foo > & D.64206) > > I think this makes sense as add_implicitly_declared_members is called > before my injection via finish_struct_1 -> check_bases_and_members. Yes, but that's because the implicit op== isn't declared lazily like some other special member functions (CLASSTYPE_LAZY_*/lazily_declare_fn) which can happen after the class is complete. > --- > > I would like some comment on the implications of: > -  { "cold",       0, 0, true,  false, false, false, > +  { "cold",      0, 0, false,  false, false, false, > > As I am now introducing a new warning that I cannot explain in an old test: > testsuite/g++.dg/Wmissing-attributes.C:55:22: warning: 'hot' attribute > ignored [-Wattributes] > > > template <> > > void* > > ATTR ((hot)) ATTR ((alloc_size (1))) ATTR ((malloc)) > > missing_all(int);   // T = char, same as above I think this is because attributes in that position appertain to the return type rather than the declaration. At attribs.cc:753, if an attribute has decl_required true and we try to apply it to a return type, we pass it along to the declaration instead; if you change the true to false we will try to apply it to void* directly and fail. I think it would work to check for (flags & (ATTR_FLAG_FUNCTION_NEXT | ATTR_FLAG_DECL_NEXT)) and return without warning in that case. You'd still set *no_add_attr. BTW the patch got garbled this time, probably safer to make it an attachment if you're using gmail. Jason