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 A93F43858288 for ; Fri, 3 Mar 2023 18:13:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A93F43858288 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=1677867188; 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=dG6ay5hx8uEZ5dBMbZPaM9tqAz2iC1TDnvYi67cOnyY=; b=Zr3RKy4yKNIyPlqXTIPQL3wvlftkFtn+m1kWyPk73jR/sVn7em0GYtj4N3X6SVHbBz3/Dk N/1Xn19QXvT5MVwa4o0mX+96zP43Iqllg7rL6E+lcvDRp4I15DzzGs6wBmAzaeeOlpChRB E1KUHlp2qT6alH+PErOfsehuD9+IjlE= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-218-GPEP9pnaMBSicwfyHKVQxQ-1; Fri, 03 Mar 2023 13:13:06 -0500 X-MC-Unique: GPEP9pnaMBSicwfyHKVQxQ-1 Received: by mail-lj1-f199.google.com with SMTP id z10-20020a2ebe0a000000b00295d38461a4so857290ljq.23 for ; Fri, 03 Mar 2023 10:13:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=dG6ay5hx8uEZ5dBMbZPaM9tqAz2iC1TDnvYi67cOnyY=; b=ZEMjHbXs/srPcv80EO04/nglDupA7gwYwtr9heSPik0PVzKA66e0ZTY+27fIvE75rY E7gjgkg5wwnncOimpJzr8F54vySEAF5VW6u85opyHe+VHabOqE34Sn25mwwVS8aH6C0c Xuk+3dmeGLmIVOpl88o9k1mEZdIcNcS7UAh1c+EnKw5zsXJm9GWrskjQVZ905gVq/IMa cxPmafVDKBAKANu2d5/3R5S/qLlBFyRL6M/a0rSRFnjrnGnQ+YbGFsoNFEKegOHutvJq /RYqTBLIzSvI3chmqVRL+I8rpqCl0Q5hiiiODD5HCEULMuPIyTWwC8DRxxfG7/8d9d9M Pblg== X-Gm-Message-State: AO0yUKUZMXtFe49+FukeUxpsXt/F7xr659BM+Wf899EjtHQvZ36vsrHy PI/dnKsZI/cMydhgZvkPg0FPdzhxbEOy/jQ9dH+M56FKdDeZzuXs6cWFnUVLWPx5l5gFNi/Qs3J sjrOKigyE6bYiFBYibBeKGgzDdSXS30Vi6Q== X-Received: by 2002:a05:6512:68:b0:4d8:5f47:e4d3 with SMTP id i8-20020a056512006800b004d85f47e4d3mr883684lfo.8.1677867185604; Fri, 03 Mar 2023 10:13:05 -0800 (PST) X-Google-Smtp-Source: AK7set/L6HzSjkU1bozZw6GZ++qsTL3izETmMbqlwwTKo5vOUwM0AaMHCLkXLphL0fwxSSh0GKUein2msMwoV62YPVQ= X-Received: by 2002:a05:6512:68:b0:4d8:5f47:e4d3 with SMTP id i8-20020a056512006800b004d85f47e4d3mr883674lfo.8.1677867185257; Fri, 03 Mar 2023 10:13:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 3 Mar 2023 18:12:53 +0000 Message-ID: Subject: Re: [libstdc++] Use __gthread_join in jthread/95989 To: Alexandre Oliva Cc: Jonathan Wakely , gcc-patches , "libstdc++" , Bernd Edlinger X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000008edc0805f602e584" X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000008edc0805f602e584 Content-Type: text/plain; charset="UTF-8" On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva wrote: > On Mar 3, 2023, Jonathan Wakely wrote: > > > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely wrote: > >> Jakub previously suggested doing this for PR 61841, which was a similar > >> problem with pthread_create: > >> > >> __asm ("" : : "r" (&pthread_create)); would not be optimized away. > >> > >> > >> That would avoid the multiple copies. > > Not really. There would be multiple copies of the code that loads > pthread_create's address. And we don't really need the address, a > single never-executed call would do. I've explored these possibilities > a bit, and here's what I've come up with: a private static member > function that we output in units that instantiate the thread template > ctor, to pass its address to _M_start_thread. Since it's never actually > called, we don't really need the hacks in some of the alternatives I > left in place, mainly for your enjoyment. > > They all work equally well, just as efficient per-instantiation at > runtime, a little different space and loading overheads, but the last > one, that is enabled, is my favorite: only PLT relocations, that we'd > likely get anyway, no full-address resolution, and as-short-as-possible > calls, enough to get a relocation with a strong reference to pull the > symbol in when linking, but as short as possible call sequences, because > of the type cast. > And those expressions aren't ever optimized away as unused? > > As a bonus, I put in (in the last minute, after my test runs) something > to keep even LTO happy: the asm statements to prevent depend from being > optimized out in _M_start_thread. In non-LTO, its impact should be > virtually zero. > > How does this look? (minus the #if 0/#elif 0/.../#else) > Looks good, thanks for going the extra mile to check all the alternatives, and the futureproofing it for LTO. OK for trunk. --0000000000008edc0805f602e584--