[PATCH] Generate gimple-match.c and generic-match.c earlier

[Richard Biener]

On Wed, Jul 14, 2021 at 3:15 PM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Wed, Jul 14, 2021 at 3:12 PM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Wed, Jul 14, 2021 at 2:48 PM Tamar Christina via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> > >
> > > Hi,
> > >
> > > Ever since this commit
> > >
> > > commit c9114f2804b91690e030383de15a24e0b738e856
> > > Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
> > > Date:   Fri May 28 06:27:27 2021 +0200
> > >
> > > Various tools have been having trouble with cross compilation resulting in
> > >
> > > make[2]: *** No rule to make target '../build-x86_64-build_pc-linux-gnu/libcpp/libcpp.a', needed by 'build/genmatch'.
> > >
> > > (took a while to track down).  I don't understand this part of the build system well enough to know how to fix this.
> > > It looks like `libcpp.a` has special handling for cross compilers which now seems to be broken.
> > >
> > > I can't reproduce it with our normal cross compiler scripts. Which handles the stages on its own, but e.g.
> > > https://github.com/crosstool-ng/crosstool-ng does reproduce the failure.
> > >
> > > Any ideas what's going on?
> >
> > There should be a dependence of all-gcc to all-build-libcpp, Makefile.def has
> >
> > dependencies = { module=all-gcc; on=all-build-libcpp; };
> >
> > so how come build-libcpp is not built when gcc/ starts?
>
> Ah, I guess (gcc/Makefile.in):
>
> CPPLIB = ../libcpp/libcpp.a
> ...
> # For stage1 and when cross-compiling use the build libcpp which is
> # built with NLS disabled.  For stage2+ use the host library and
> # its dependencies.
> ifeq ($(build_objdir),$(build_libobjdir))
> BUILD_CPPLIB = $(build_libobjdir)/libcpp/libcpp.a
> else
> BUILD_CPPLIB = $(CPPLIB) $(LIBIBERTY)
>
> is not properly reflected in above dependences.  Not sure how to fix
> that though.

I guess add

 dependencies = { module=all-gcc; on=all-libcpp; };

like it is done for libiberty.

> > > Kind Regards,
> > > Tamar
> > >
> > > > -----Original Message-----
> > > > From: Gcc-patches <gcc-patches-bounces@gcc.gnu.org> On Behalf Of
> > > > Michael Matz
> > > > Sent: Friday, May 28, 2021 4:33 PM
> > > > To: Bernd Edlinger <bernd.edlinger@hotmail.de>
> > > > Cc: gcc-patches@gcc.gnu.org; Richard Biener <rguenther@suse.de>
> > > > Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c earlier
> > > >
> > > > Hello,
> > > >
> > > > On Fri, 28 May 2021, Bernd Edlinger wrote:
> > > >
> > > > > >> I was wondering, why gimple-match.c and generic-match.c are not
> > > > > >> built early but always last, which slows down parallel makes
> > > > > >> significantly.
> > > > > >>
> > > > > >> The reason seems to be that generated_files does not mention
> > > > > >> gimple-match.c and generic-match.c.
> > > > > >>
> > > > > >> This comment in Makefile.in says it all:
> > > > > >>
> > > > > >> $(ALL_HOST_OBJS) : | $(generated_files)
> > > > > >>
> > > > > >> So this patch adds gimple-match.c generic-match.c to generated_files.
> > > > > >>
> > > > > >>
> > > > > >> Tested on x86_64-pc-linux-gnu.
> > > > > >> Is it OK for trunk?
> > > > > >
> > > > > > This should help for what I was complaining about in
> > > > > > https://gcc.gnu.org/pipermail/gcc/2021-May/235963.html . I build
> > > > > > with
> > > > > > -j24 and it was stalling on compiling gimple-match.c for me.
> > > > > > Looks like insn-attrtab.c is missed too; I saw genattrtab was running last
> > > > too.
> > > > > >
> > > > >
> > > > > Yeah, probably insn-automata.c as well, sometimes it is picked up
> > > > > early sometimes not. maybe $(simple_generated_c) should be added to
> > > > > generated_files, but insn-attrtab.c is yet another exception.
> > > >
> > > > You can't put files in there that are sometimes slow to generate (which insn-
> > > > {attrtab,automata}.c are on some targets), as _everything_ then waits for
> > > > them to be created first.
> > > >
> > > > Ideally there would be a way for gnumake to mark some targets as "ugh-
> > > > slow" and back-propagate this to all dependencies so that those are put in
> > > > front of the work queue in a parallel make.  Alas, something like that never
> > > > came into existence :-/  (When order-only deps were introduced I got
> > > > excited, but then came to realize that that wasn't what was really needed for
> > > > this case, a "weak" version of it would be required at least, or better yet a
> > > > specific facility to impose a cost with a target)
> > > >
> > > >
> > > > Ciao,
> > > > Michael.
> > > >
> > > > >
> > > > >
> > > > > Bernd.
> > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >> Thanks
> > > > > >> Bernd.
> > > > > >>
> > > > > >>
> > > > > >> 2021-05-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>
> > > > > >>
> > > > > >>         * Makefile.in (generated_files): Add gimple-match.c and
> > > > > >>         generic-match.c
> > > > >