Message ID | 20220519081015.266945-1-yangyujie@loongson.cn |
---|---|
State | Committed |
Commit | 75df1594ae56dcdcc471f138e088cfa81c48082b |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8C51F384F029 for <patchwork@sourceware.org>; Thu, 19 May 2022 08:10:44 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id A7ECE38515F3; Thu, 19 May 2022 08:10:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A7ECE38515F3 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from 5.5.5 (unknown [10.2.5.5]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9Ax+ths+4ViPfYbAA--.26725S2; Thu, 19 May 2022 16:10:23 +0800 (CST) From: Yang Yujie <yangyujie@loongson.cn> To: gcc-patches@gcc.gnu.org, jit@gcc.gnu.org Subject: [PATCH v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS) Date: Thu, 19 May 2022 16:10:15 +0800 Message-Id: <20220519081015.266945-1-yangyujie@loongson.cn> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf9Ax+ths+4ViPfYbAA--.26725S2 X-Coremail-Antispam: 1UD129KBjvJXoW7uFW7JFyDtF43tr17GF15Jwb_yoW5JrW3pa 4rCw13XF48Ja4Yka97J3W8Za4UCFWrJr1kXFy5Wr47Aa4YganIvF4vyw12vFZxJw4ft39r u3sYgr1jy3WDJ3JanT9S1TB71UUUUUJqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvY14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAaw2AFwI0_Jrv_JF1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE 5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1l c2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWU twCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Zr0_Wr1UMIIF0xvEx4A2jsIE14v2 6r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0J Uho7tUUUUU= X-CM-SenderInfo: 51dqw5pxmlvqxorr0wxvrqhubq/ X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_PASS, 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Cc: xuchenghua@loongson.cn, Yang Yujie <yangyujie@loongson.cn> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
[v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)
|
|
Commit Message
Yang Yujie
May 19, 2022, 8:10 a.m. UTC
Hello, This patch fixes libgccjit build failure on loongarch* targets, and could probably be useful for future ports. For now, libgccjit is linked with objects from $(EXTRA_GCC_OBJS) and libbackend.a, which contains object files from $(EXTRA_OBJS). This effectively forbids any overlap between those two lists, i.e. all target-specific shared code between the gcc driver and compiler executables must go into gcc/common/config/<arch>/<arch>-common.cc, which feels a bit inconvenient when there are a lot of "common" stuff that we want to put into separate source files. By linking libgccjit with $(EXTRA_GCC_OBJS_EXCLUSIVE), which contains all elements from $(EXTRA_GCC_OBJS) but not $(EXTRA_OBJS), this problem can be alleviated. This patch does not affect any other target architecture than loongarch, and has been bootstrapped and regression-tested on loongarch64-linux-gnuf64 an x86_64-pc-linux-gnu. Any recommendations? Please review. Thanks a lot. Yujie * gcc/jit/ChangeLog: * Make-lang.in: only link objects from $(EXTRA_GCC_OBJS) that's not in $(EXTRA_OBJS) into libgccjit. --- gcc/jit/Make-lang.in | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
Comments
Ping. I'd like to see libgccjit working on LoongArch so I would be able to submit a Rust port to upstream. If the result is NACK I'd like to know alternative approaches to fix the build failure. I doubt if "jit@gcc.gnu.org" is really used, so CC'ed the JIT maintainer listed in MAINTAINERS. On Thu, 2022-05-19 at 16:10 +0800, Yang Yujie wrote: > Hello, > > This patch fixes libgccjit build failure on loongarch* targets, > and could probably be useful for future ports. > > For now, libgccjit is linked with objects from $(EXTRA_GCC_OBJS) and > libbackend.a, which contains object files from $(EXTRA_OBJS). > > This effectively forbids any overlap between those two lists, i.e. all > target-specific shared code between the gcc driver and compiler > executables must go into gcc/common/config/<arch>/<arch>-common.cc, > which feels a bit inconvenient when there are a lot of "common" stuff > that we want to put into separate source files. > > By linking libgccjit with $(EXTRA_GCC_OBJS_EXCLUSIVE), which contains > all elements from $(EXTRA_GCC_OBJS) but not $(EXTRA_OBJS), this > problem > can be alleviated. > > This patch does not affect any other target architecture than > loongarch, > and has been bootstrapped and regression-tested on loongarch64-linux- > gnuf64 > an x86_64-pc-linux-gnu. > > Any recommendations? Please review. Thanks a lot. > > Yujie > > * gcc/jit/ChangeLog: > > * Make-lang.in: only link objects from $(EXTRA_GCC_OBJS) > that's not in $(EXTRA_OBJS) into libgccjit. > --- > gcc/jit/Make-lang.in | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in > index 6e10abfd0ac..248ec45b729 100644 > --- a/gcc/jit/Make-lang.in > +++ b/gcc/jit/Make-lang.in > @@ -157,18 +157,23 @@ LIBGCCJIT_EXTRA_OPTS = > $(LIBGCCJIT_VERSION_SCRIPT_OPTION) \ > endif > endif > > +# Only link objects from $(EXTRA_GCC_OBJS) that's not already > +# included in libbackend.a ($(EXTRA_OBJS)). > +EXTRA_GCC_OBJS_EXCLUSIVE = $(foreach _obj1, $(EXTRA_GCC_OBJS), \ > + $(if $(filter $(_obj1), $(EXTRA_OBJS)),, $(_obj1))) > + > # We avoid using $(BACKEND) from Makefile.in in order to avoid > pulling > # in main.o > $(LIBGCCJIT_FILENAME): $(jit_OBJS) \ > libbackend.a libcommon-target.a libcommon.a \ > $(CPPLIB) $(LIBDECNUMBER) \ > $(LIBDEPS) $(srcdir)/jit/libgccjit.map \ > - $(EXTRA_GCC_OBJS) $(jit.prev) > + $(EXTRA_GCC_OBJS_EXCLUSIVE) $(jit.prev) > @$(call LINK_PROGRESS,$(INDEX.jit),start) > +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ -shared \ > $(jit_OBJS) libbackend.a libcommon-target.a libcommon.a \ > $(CPPLIB) $(LIBDECNUMBER) $(EXTRA_GCC_LIBS) $(LIBS) > $(BACKENDLIBS) \ > - $(EXTRA_GCC_OBJS) \ > + $(EXTRA_GCC_OBJS_EXCLUSIVE) \ > $(LIBGCCJIT_EXTRA_OPTS) > @$(call LINK_PROGRESS,$(INDEX.jit),end) >
On Mon, 2022-05-30 at 18:09 +0800, Xi Ruoyao wrote: > Ping. I'd like to see libgccjit working on LoongArch so I would be > able > to submit a Rust port to upstream. > > If the result is NACK I'd like to know alternative approaches to fix > the > build failure. > > I doubt if "jit@gcc.gnu.org" is really used, so CC'ed the JIT > maintainer > listed in MAINTAINERS. Sorry about that, it turns out there's something wrong with my email filters. Unfortunately, I haven't been able to fix them, so please CC me directly on jit-related patches, and do ping me if I seem not to have seen one. Sorry again. > > On Thu, 2022-05-19 at 16:10 +0800, Yang Yujie wrote: > > Hello, > > > > This patch fixes libgccjit build failure on loongarch* targets, > > and could probably be useful for future ports. > > > > For now, libgccjit is linked with objects from $(EXTRA_GCC_OBJS) > > and > > libbackend.a, which contains object files from $(EXTRA_OBJS). > > > > This effectively forbids any overlap between those two lists, i.e. > > all > > target-specific shared code between the gcc driver and compiler > > executables must go into gcc/common/config/<arch>/<arch>-common.cc, > > which feels a bit inconvenient when there are a lot of "common" > > stuff > > that we want to put into separate source files. > > > > By linking libgccjit with $(EXTRA_GCC_OBJS_EXCLUSIVE), which > > contains > > all elements from $(EXTRA_GCC_OBJS) but not $(EXTRA_OBJS), this > > problem > > can be alleviated. Yujie: thanks for figuring this out, and coming up with a solution. Presumably libgccjit is the only GCC "frontend" that also has driver code directly linked into it, and thus the only one that needs this workaround. > > > > This patch does not affect any other target architecture than > > loongarch, > > and has been bootstrapped and regression-tested on loongarch64- > > linux- > > gnuf64 > > an x86_64-pc-linux-gnu. > > > > Any recommendations? Please review. Thanks a lot. The patch looks good to me. Thanks. Dave > > > > Yujie > > > > * gcc/jit/ChangeLog: > > > > * Make-lang.in: only link objects from $(EXTRA_GCC_OBJS) > > that's not in $(EXTRA_OBJS) into libgccjit. > > --- > > gcc/jit/Make-lang.in | 9 +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in > > index 6e10abfd0ac..248ec45b729 100644 > > --- a/gcc/jit/Make-lang.in > > +++ b/gcc/jit/Make-lang.in > > @@ -157,18 +157,23 @@ LIBGCCJIT_EXTRA_OPTS = > > $(LIBGCCJIT_VERSION_SCRIPT_OPTION) \ > > endif > > endif > > > > +# Only link objects from $(EXTRA_GCC_OBJS) that's not already > > +# included in libbackend.a ($(EXTRA_OBJS)). > > +EXTRA_GCC_OBJS_EXCLUSIVE = $(foreach _obj1, $(EXTRA_GCC_OBJS), \ > > + $(if $(filter $(_obj1), $(EXTRA_OBJS)),, $(_obj1))) > > + > > # We avoid using $(BACKEND) from Makefile.in in order to avoid > > pulling > > # in main.o > > $(LIBGCCJIT_FILENAME): $(jit_OBJS) \ > > libbackend.a libcommon-target.a libcommon.a \ > > $(CPPLIB) $(LIBDECNUMBER) \ > > $(LIBDEPS) $(srcdir)/jit/libgccjit.map \ > > - $(EXTRA_GCC_OBJS) $(jit.prev) > > + $(EXTRA_GCC_OBJS_EXCLUSIVE) $(jit.prev) > > @$(call LINK_PROGRESS,$(INDEX.jit),start) > > +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ -shared \ > > $(jit_OBJS) libbackend.a libcommon-target.a > > libcommon.a \ > > $(CPPLIB) $(LIBDECNUMBER) $(EXTRA_GCC_LIBS) $(LIBS) > > $(BACKENDLIBS) \ > > - $(EXTRA_GCC_OBJS) \ > > + $(EXTRA_GCC_OBJS_EXCLUSIVE) \ > > $(LIBGCCJIT_EXTRA_OPTS) > > @$(call LINK_PROGRESS,$(INDEX.jit),end) > > >
On Mon, 2022-06-06 at 18:33 -0400, David Malcolm wrote: > > On Thu, 2022-05-19 at 16:10 +0800, Yang Yujie wrote: > > > This patch does not affect any other target architecture than > > > loongarch, > > > and has been bootstrapped and regression-tested on loongarch64- > > > linux- > > > gnuf64 > > > an x86_64-pc-linux-gnu. > > > > > > Any recommendations? Please review. Thanks a lot. > > The patch looks good to me. Pushed as r13-1010.
diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in index 6e10abfd0ac..248ec45b729 100644 --- a/gcc/jit/Make-lang.in +++ b/gcc/jit/Make-lang.in @@ -157,18 +157,23 @@ LIBGCCJIT_EXTRA_OPTS = $(LIBGCCJIT_VERSION_SCRIPT_OPTION) \ endif endif +# Only link objects from $(EXTRA_GCC_OBJS) that's not already +# included in libbackend.a ($(EXTRA_OBJS)). +EXTRA_GCC_OBJS_EXCLUSIVE = $(foreach _obj1, $(EXTRA_GCC_OBJS), \ + $(if $(filter $(_obj1), $(EXTRA_OBJS)),, $(_obj1))) + # We avoid using $(BACKEND) from Makefile.in in order to avoid pulling # in main.o $(LIBGCCJIT_FILENAME): $(jit_OBJS) \ libbackend.a libcommon-target.a libcommon.a \ $(CPPLIB) $(LIBDECNUMBER) \ $(LIBDEPS) $(srcdir)/jit/libgccjit.map \ - $(EXTRA_GCC_OBJS) $(jit.prev) + $(EXTRA_GCC_OBJS_EXCLUSIVE) $(jit.prev) @$(call LINK_PROGRESS,$(INDEX.jit),start) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ -shared \ $(jit_OBJS) libbackend.a libcommon-target.a libcommon.a \ $(CPPLIB) $(LIBDECNUMBER) $(EXTRA_GCC_LIBS) $(LIBS) $(BACKENDLIBS) \ - $(EXTRA_GCC_OBJS) \ + $(EXTRA_GCC_OBJS_EXCLUSIVE) \ $(LIBGCCJIT_EXTRA_OPTS) @$(call LINK_PROGRESS,$(INDEX.jit),end)