From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) by sourceware.org (Postfix) with ESMTPS id 93295385782A for ; Sat, 12 Jun 2021 15:55:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93295385782A Received: by mail-qk1-x729.google.com with SMTP id c18so19150274qkc.11 for ; Sat, 12 Jun 2021 08:55:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=6u/im8bAscBS/oHTazIczsd8V5SEwf5MhaPYWNus+CI=; b=onuvqx0TQOZecgDE9VfNrtzpS9qsZ3na/EEJzzE8j0LfaWU3lqzlxP6436jvbhSVyO o/Ofl4j5xOi8H7zsqBfdc+Hcw9+phQcqAHUHrJ5LZ2azQ1afT5grbUOzEsi3+tnrJ2lh 7zcUKIYnfiuKKbDPvb/MPGZwZbwbjB43W7WSb8kT1S6xqktVzl2Hjv3OLzMwdurDNIM0 IyeCQ+qDbH5TpH+YCicOPSjSft3E/ddPbw6Nl3SZgt7amrEefJ6C9NB9arjnxoMA0K8q 7sQCdId9uWn1VbnKqx3m0+6bLWW0U6ND+qe5cd/mtbt3eV9LP3L8gRpNNVlzAxpVZg/H EHdQ== X-Gm-Message-State: AOAM533ccQYAFIE1JkNzdPV7BRMu9HtPcc7YZ3JHuUZcZbuzitMWxYUO kU0W7VG5yLuqfxqslb6iFHXaTg== X-Google-Smtp-Source: ABdhPJwJuoynTfuep8Pmma2ZIx9V9kgy9gGwk8lJkzpMv/xt6WlPV9E66vws7Mqp0CeDoLGjEJ3lGw== X-Received: by 2002:a37:a405:: with SMTP id n5mr9116112qke.186.1623513351030; Sat, 12 Jun 2021 08:55:51 -0700 (PDT) Received: from [192.168.0.18] ([186.207.70.210]) by smtp.gmail.com with ESMTPSA id b189sm6739378qkc.91.2021.06.12.08.55.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Jun 2021 08:55:50 -0700 (PDT) Message-ID: <4faefc75a37f86030464d16c59932fe273785b6f.camel@usp.br> Subject: Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c) From: Giuliano Belinassi To: Richard Biener , Martin =?UTF-8?Q?Li=C5=A1ka?= , Jan Hubicka Cc: GCC Mailing List , GCC Patches , Segher Boessenkool Date: Sat, 12 Jun 2021 12:55:46 -0300 In-Reply-To: References: <20210511145904.GM10366@gate.crashing.org> <20210512121248.GU10366@gate.crashing.org> <5f13a740-5eff-886f-2b29-52a305fdf3b1@suse.cz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Sat, 12 Jun 2021 15:55:54 -0000 Hi, all. Please CC me when I am mentioned into a mail. On Thu, 2021-05-20 at 15:16 +0200, Richard Biener via Gcc wrote: > On Thu, May 20, 2021 at 3:06 PM Martin Liška wrote: > > > > On 5/20/21 2:54 PM, Richard Biener wrote: > > > So why did you go from applying this per-file to multiple files? > > > > When I did per-file for {gimple,generic}-match.c I hit the > > following issue with lto.priv symbols: > > > > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse- > > linux/bin/ld: error: libbackend.a(generic-match.o): multiple > > definition of 'wi::to_wide(tree_node const*) [clone .part.0] [clone > > .lto_priv.0]' > > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse- > > linux/bin/ld: libbackend.a(gimple-match.o): previous definition > > here > > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse- > > linux/bin/ld: error: libbackend.a(generic-match.o): multiple > > definition of 'TYPE_VECTOR_SUBPARTS(tree_node const*) [clone > > .part.0] [clone .lto_priv.0]' > > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse- > > linux/bin/ld: libbackend.a(gimple-match.o): previous definition > > here > > /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse- > > linux/bin/ld: error: libbackend.a(generic-match.o): multiple > > definition of 'vec > vl_embed>::operator[](unsigned int) [clone .part.0] [clone > > .lto_priv.0]' > > > > Any idea what was I doing wrong? > > Nothing in particular I think - you're just hitting the issue that > LTO > produces new symbols and that those > can obviously clash.  Giuliano hit the very same issue.  When not > doing partial links those internal > symbols pose no problem, but with -r -flinker-output=nolto-rel and > re-linking the produced objects > they obviously do.  ELF has no solution for this though, but I think > we could strip those from the > partially linked object - if WPA would give us a list of objects the > link step could postprocess > the object with objcopy or maybe a custom linker script could do the > trick as well. I've "fixed" this issue in my branch by mangling any promoted to public symbol. I've also disabled the "ipa-split" pass in the paper branch because of some created symbols which I was not able to fix in time. Perhaps this goes away if you disable it. Perhaps we should work on getting the autopar branch merged into trunk. There are several issues which must be fixed and I don't think it will be ready for this next release. The main ones that I remember from the top of my head: 1- Fix the driver to use SPEC language for the multiple required calls to `as`, instead of injecting code for that directly on the `void execute()` function. 2- Merge my custom partitioner for using the default LTO partitioner. The default LTO partitioner were hitting the assertions about COMDAT being split into multiple partitions. 3- Fix the issue with the ipa-split pass. Perhaps we should further explore avoiding partial linking altogether and concat the assembler files. Thank you, Giuliano. > > So your workaround is to only ever have a single LTO produced object > file participating in the > final links ;) > > Richard. > > > > > Martin