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 801DA3858296 for ; Fri, 3 Mar 2023 18:13:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 801DA3858296 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=1677867190; 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=TVNX4Quj5ibNJlO6DYr+tYoZ9Ac2tUYeDuZSpI20djsfT5LzH4kAmRfLmt4oQh2i5j2mQK Q6wWvGRXfiJEv6UfWXlbYX8d7iG3lZsqdty4g2rIkQHW00X+Axmw3nNhbayW9L4nq0Cyfs 8aaJZCRDiSpAQQRh+JFDNN1bGTdth2U= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-218-rjcR18W3MOe6b32Y991tFw-1; Fri, 03 Mar 2023 13:13:06 -0500 X-MC-Unique: rjcR18W3MOe6b32Y991tFw-1 Received: by mail-lj1-f197.google.com with SMTP id a2-20020a2e8602000000b00295cb325fd5so858134lji.3 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=x1j+TlqztEXsbw76jOXa7Lku87F7uOPGqgKTEiT589aM8ObWZrndYES/96/E7Bkv0v xN40ay7yYxAuj0ZvA0PlxBeNPks+salg0HQxhkJj/eaj0QKh02e0vNaM2r2DrsPGEwz0 UsKbO3O/M21uzDygQEGz8OXoYaXsCLyjeJOAseeVXQO7DxdQDCeP1gzf6f5n+sT5qcVI mnw6n+LT8MzRiRkipAKs9gK+7AYmXQGNfHSv5TGP/awmmKbUKt5AG13x/25Hd781gkEd qwBOP8HU0SOsuYLQLfvUhtrZ80hmKq3Zy41gxBXY9PFhgQJwWdPiVnKZHVJgpQFGZUil u3jQ== X-Gm-Message-State: AO0yUKX1nOj6abj1tJYFm3COC8LiEZgBX0uKn2ClCaufkd465Ce4zynh UyfUavVkMeE+JALAowsOtBQloJYDJ5O+6uD9Nw2QTzsy4DZXHr06Fa3yjLSiGCWC8EkykC84YXp cE/hbh/hOU0YxjHdn0NLpOI4hSbn8kuU= X-Received: by 2002:a05:6512:68:b0:4d8:5f47:e4d3 with SMTP id i8-20020a056512006800b004d85f47e4d3mr883682lfo.8.1677867185503; 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=-6.0 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--