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

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

[Bernd Edlinger]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Hi,

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?


Thanks
Bernd.


2021-05-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	* Makefile.in (generated_files): Add gimple-match.c and
	generic-match.c

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Generate-gimple-match.c-and-generic-match.c-earlier.patch --]
[-- Type: text/x-patch; name="0001-Generate-gimple-match.c-and-generic-match.c-earlier.patch", Size: 1398 bytes --]

From 5c14c3f5852ddcc1d3b76e7c53260b0187604cd7 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date: Fri, 28 May 2021 06:27:27 +0200
Subject: [PATCH] Generate gimple-match.c and generic-match.c earlier

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.

2021-05-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	* Makefile.in (generated_files): Add gimple-match.c and
	generic-match.c
---
 gcc/Makefile.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index da2ef24..4cb2966 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2753,6 +2753,7 @@ generated_files = config.h tm.h $(TM_P_H) $(TM_D_H) $(TM_H) multilib.h \
        $(ALL_GTFILES_H) gtype-desc.c gtype-desc.h version.h \
        options.h target-hooks-def.h insn-opinit.h \
        common/common-target-hooks-def.h pass-instances.def \
+       gimple-match.c generic-match.c \
        c-family/c-target-hooks-def.h d/d-target-hooks-def.h \
        case-cfn-macros.h \
        cfn-operators.pd omp-device-properties.h
-- 
1.9.1

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

[Bernd Edlinger]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]



On 5/28/21 6:42 AM, Bernd Edlinger wrote:
> Hi,
> 
> 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:
> 

Oh, dear, git commit did eliminate the comments
starting with "#"
the mentined comment is

# Dependency information.

# In order for parallel make to really start compiling the expensive
# objects from $(OBJS) as early as possible, build all their
# prerequisites strictly before all objects.

> $(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?
> 
> 
> Thanks
> Bernd.
> 
> 
> 2021-05-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>
> 
> 	* Makefile.in (generated_files): Add gimple-match.c and
> 	generic-match.c
> 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Generate-gimple-match.c-and-generic-match.c-earlier.patch --]
[-- Type: text/x-patch; name="0001-Generate-gimple-match.c-and-generic-match.c-earlier.patch", Size: 1529 bytes --]

From 99eab77ebfaa02ee22263d89eb3ca812cf65263b Mon Sep 17 00:00:00 2001
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date: Fri, 28 May 2021 06:27:27 +0200
Subject: [PATCH] Generate gimple-match.c and generic-match.c earlier

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:

"In order for parallel make to really start compiling the expensive
objects from $(OBJS) as early as possible, build all their
prerequisites strictly before all objects."

So this patch adds gimple-match.c generic-match.c to generated_files.

2021-05-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	* Makefile.in (generated_files): Add gimple-match.c and
	generic-match.c
---
 gcc/Makefile.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index da2ef24..4cb2966 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2753,6 +2753,7 @@ generated_files = config.h tm.h $(TM_P_H) $(TM_D_H) $(TM_H) multilib.h \
        $(ALL_GTFILES_H) gtype-desc.c gtype-desc.h version.h \
        options.h target-hooks-def.h insn-opinit.h \
        common/common-target-hooks-def.h pass-instances.def \
+       gimple-match.c generic-match.c \
        c-family/c-target-hooks-def.h d/d-target-hooks-def.h \
        case-cfn-macros.h \
        cfn-operators.pd omp-device-properties.h
-- 
1.9.1

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

[Richard Biener]

On Fri, 28 May 2021, Bernd Edlinger wrote:

> 
> 
> On 5/28/21 6:42 AM, Bernd Edlinger wrote:
> > Hi,
> > 
> > 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:
> > 
> 
> Oh, dear, git commit did eliminate the comments
> starting with "#"
> the mentined comment is
> 
> # Dependency information.
> 
> # In order for parallel make to really start compiling the expensive
> # objects from $(OBJS) as early as possible, build all their
> # prerequisites strictly before all objects.
> 
> > $(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?

OK.  Does it really help though?

Thanks,
Richard.

> > 
> > 
> > Thanks
> > Bernd.
> > 
> > 
> > 2021-05-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>
> > 
> > 	* Makefile.in (generated_files): Add gimple-match.c and
> > 	generic-match.c
> > 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

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

[Bernd Edlinger]

On 5/28/21 8:41 AM, Richard Biener wrote:
> On Fri, 28 May 2021, Bernd Edlinger wrote:
> 
>>
>>
>> On 5/28/21 6:42 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> 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:
>>>
>>
>> Oh, dear, git commit did eliminate the comments
>> starting with "#"
>> the mentined comment is
>>
>> # Dependency information.
>>
>> # In order for parallel make to really start compiling the expensive
>> # objects from $(OBJS) as early as possible, build all their
>> # prerequisites strictly before all objects.
>>
>>> $(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?
> 
> OK.  Does it really help though?
> 

Yes, I guess so, at least a little bit.

Prior to this patch the whole build stage was completed for everything
then those two big files got generated,
and then there are only two large files compiled in parallel for
several minutes at least.

So a make -j8 utilizes only 25 % cpu power
and make -j16 only 12.5 % utilization.
That can certainly be a bit annoying.


Bernd.


> Thanks,
> Richard.
> 
>>>
>>>
>>> Thanks
>>> Bernd.
>>>
>>>
>>> 2021-05-28  Bernd Edlinger  <bernd.edlinger@hotmail.de>
>>>
>>> 	* Makefile.in (generated_files): Add gimple-match.c and
>>> 	generic-match.c
>>>
>>
> 

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

[Andrew Pinski]

On Thu, May 27, 2021 at 10:10 PM Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
>
> Hi,
>
> 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.

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

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

[Bernd Edlinger]

On 5/28/21 9:26 AM, Andrew Pinski wrote:
> On Thu, May 27, 2021 at 10:10 PM Bernd Edlinger
> <bernd.edlinger@hotmail.de> wrote:
>>
>> Hi,
>>
>> 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.


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

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

[Jakub Jelinek]

On Fri, May 28, 2021 at 09:33:14AM +0200, Bernd Edlinger wrote:
> > 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.

The problem with insn-automata.c is that on some targets it is very time
consuming to generate that file (I think e.g. s390x) and by putting it into
generated_files it could actually hurt the build speed because everything
will be waiting on insn-automata.c generation for 1-2 minutes or how long
before anything else can be built.

	Jakub

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

[Michael Matz]

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
> 

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

[Tamar Christina]

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?

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
> >

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

[Richard Biener]

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?

> 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
> > >

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

[Richard Biener]

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.

> > 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
> > > >

Re: [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
> > > > >

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

[Tamar Christina]

> -----Original Message-----
> From: Richard Biener <richard.guenther@gmail.com>
> Sent: Wednesday, July 14, 2021 2:19 PM
> To: Tamar Christina <Tamar.Christina@arm.com>
> Cc: Michael Matz <matz@suse.de>; Bernd Edlinger
> <bernd.edlinger@hotmail.de>; Richard Biener <rguenther@suse.de>; gcc-
> patches@gcc.gnu.org
> Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c earlier
> 
> 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; };
> 

Isn't that already there? I see

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

already in Makefile.def

Regards,
Tamar

> 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
> > > > > >

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

[Bernd Edlinger]

On 7/14/21 2:47 PM, Tamar Christina 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.
> 

Sorry for the breakage!

I do not know this tool at all, but this here looks suspicious,
as it it by-passes the dependencies in the top-level Makefile:

https://github.com/crosstool-ng/crosstool-ng/blob/755850d07ec4e8dc44787d1a0e35fe19507f17f6/scripts/build/cc/gcc.sh#L682-L683
            CT_DoExecLog CFG make ${CT_JOBSFLAGS} configure-gcc configure-libcpp configure-build-libiberty
            CT_DoExecLog ALL make ${CT_JOBSFLAGS} all-libcpp all-build-libiberty
...
https://github.com/crosstool-ng/crosstool-ng/blob/755850d07ec4e8dc44787d1a0e35fe19507f17f6/scripts/build/cc/gcc.sh#L711-L712
        CT_DoExecLog ALL make ${CT_JOBSFLAGS} -C gcc ${libgcc_rule} \
                              ${repair_cc}


but the top-level Makefile has also a dependency to all-build-libcpp:

dependencies = { module=all-gcc; on=all-build-libcpp; };
dependencies = { module=all-gcc; on=all-libcpp; hard=true; };

Maybe this just worked by chance, when building with "make -j" started a parallel build,
might build the build-libcpp dependency eventually, but due to the patch it is
needed earlier?


Bernd.



> Any ideas what's going on?
> 
> 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
>>>

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

[Tamar Christina]

> -----Original Message-----
> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> Sent: Wednesday, July 14, 2021 4:56 PM
> To: Tamar Christina <Tamar.Christina@arm.com>; Michael Matz
> <matz@suse.de>
> Cc: gcc-patches@gcc.gnu.org; Richard Biener <rguenther@suse.de>
> Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c earlier
> 
> On 7/14/21 2:47 PM, Tamar Christina 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.
> >
> 
> Sorry for the breakage!
> 
> I do not know this tool at all, but this here looks suspicious, as it it by-passes
> the dependencies in the top-level Makefile:
> 
> https://github.com/crosstool-ng/crosstool-
> ng/blob/755850d07ec4e8dc44787d1a0e35fe19507f17f6/scripts/build/cc/gcc.s
> h#L682-L683
>             CT_DoExecLog CFG make ${CT_JOBSFLAGS} configure-gcc configure-
> libcpp configure-build-libiberty
>             CT_DoExecLog ALL make ${CT_JOBSFLAGS} all-libcpp all-build-
> libiberty ...
> https://github.com/crosstool-ng/crosstool-
> ng/blob/755850d07ec4e8dc44787d1a0e35fe19507f17f6/scripts/build/cc/gcc.s
> h#L711-L712
>         CT_DoExecLog ALL make ${CT_JOBSFLAGS} -C gcc ${libgcc_rule} \
>                               ${repair_cc}
> 
> 
> but the top-level Makefile has also a dependency to all-build-libcpp:
> 
> dependencies = { module=all-gcc; on=all-build-libcpp; }; dependencies =
> { module=all-gcc; on=all-libcpp; hard=true; };
> 
> Maybe this just worked by chance, when building with "make -j" started a
> parallel build, might build the build-libcpp dependency eventually, but due to
> the patch it is needed earlier?

Ah I didn't notice they bypassed the top level makefile, this would explain why I can't reproduce it with my own scripts..

Thanks! I'll file a bug with them then.

Kind Regards,
Tamar

> 
> 
> Bernd.
> 
> 
> 
> > Any ideas what's going on?
> >
> > 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
> >>>