From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 6D6943858D32 for ; Sun, 15 May 2022 10:01:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D6943858D32 Received: by mail-oi1-x22c.google.com with SMTP id j12so15350111oie.1 for ; Sun, 15 May 2022 03:01:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hV1ihOMWegxVN50GWdaT+ot8brbrwsnfPE8TPeQ75Ew=; b=AUmkirQ4k4aygEM5mm0sQ5flL/cuh5PaU3M2dRp379HXz9P8L/498332ZPX5HksOQs D1Q41yAMZG4y3IDN+pXbYbwvzzvUfIJ6CNNXxkWKB/JJ6HC+bEnkhU/WkMuxBo8IxTOA pqyJXTVF3vZFkekBysP+N3WB9xTcFUmJuo7I4q8EBBxlgRL71xPkKUswC3R/eYdRialR t1SOmUtOR/dGT08UTkkAv0g1jmlF2XGY/GE38yFCwwdKzUVqhgf/mVJR/qntIkKecrZw wU4YERl1tA+XmWXriw2Vtvoz3AbucmfkTP0wqVUCb/uE5zcOnYPADQxizKY+a/IaBuDv iYjQ== X-Gm-Message-State: AOAM530AUC43p8rV/vlZcam5UVFqp9Qb7eotxYngtmvfleRP6UYZE5s+ lA98z496r01IUHN/lUXQomuV33z8v/CBSTRUnC8= X-Google-Smtp-Source: ABdhPJzji2lBTKelovpBo730dALgkPDSrC48gRrhwFX4DlqCz/lhnvfe2WsJmwxauEk85I/moV0MPLY6NsA7EVzpxH8= X-Received: by 2002:a05:6808:170b:b0:2fa:729a:a42e with SMTP id bc11-20020a056808170b00b002fa729aa42emr11176937oib.0.1652608907260; Sun, 15 May 2022 03:01:47 -0700 (PDT) MIME-Version: 1.0 References: <63633ead-aa7e-c424-9851-ac332ac13df3@suse.cz> <27841a42-baef-d53e-c601-ad265030854d@suse.cz> <80f37f2-efdf-673-a8f4-69f2d5842ea2@ispras.ru> <9de185b3-914-8522-7eb-40b802d4651@ispras.ru> In-Reply-To: From: Rui Ueyama Date: Sun, 15 May 2022 18:01:36 +0800 Message-ID: Subject: Re: [PATCH] lto-plugin: add support for feature detection To: Alexander Monakov Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , GCC Patches , Jan Hubicka Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2022 10:01:50 -0000 On Sun, May 15, 2022 at 4:51 PM Alexander Monakov wrote: > > On Sun, 15 May 2022, Rui Ueyama wrote: > > > > Is that a good tradeoff in the LTO case though? I believe you cannot assume > > > the plugin to be thread-safe, so you're serializing its API calls, right? > > > But the plugin is doing a lot of work, so using the index to feed it with as > > > few LTO objects as possible should be a significant win, no? (even if it > > > was thread-safe) > > > > Oh, I didn't know that claim_file_hook isn't thread-safe. I need to add a > > lock to guard it then. But is it actually the case? > > You can see for yourself at > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=lto-plugin/lto-plugin.c > (e.g. how claim_file_handler increments the global variable num_claimed_files) > > > As to the tradeoff, speculatively loading all object files from archives > > may not be beneficial if the loaded files are LTO object files. But we do > > this for consistency. We don't have a multi-phase name resolution pass at > > all in mold; all symbols are resolved at once in parallel. We don't want > > to implement another name resolution pass just for LTO for the following > > reasons: > > > > 1. It bloats up the linker's code. > > > > 2. We don't know whether an archive file contains an LTO object file or > > not until we actually read archive members, so there's no chance to switch > > to the multi-pass name resolution algorithm before we read files. > > > > 3. If we have two different name resolution algorithms, it is very hard to > > guarantee that both algorithms produce the same result. As a result, the > > output with -flto may behave differently without -flto. > > Well, -flto can result in observably different results for other reasons > anyway. > > > 4. We still have to handle --start-libs and --end-libs, so feeding an > > object file that will end up not being included into the output is > > unavoidable. > > Makes sense, but I still don't understand why mold wants to discover in > advance whether the plugin is going to use get_symbols_v3. How would it > help with what mold does today to handle the _v2 case? Currently, mold restarts itself to reset the internal state of the plugin. If we know in advance that get_symbols_v3 is supported, we can avoid that restart. That should make the linker a bit faster. Also, restarting the linker is a hack, so we want to avoid it if possible.