This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Makefile] Split STAGESTUFF into STAGE{COPY,MOVE}STUFF


> I can't decide whether we actually *want* to rebuild those files
> during bootstrap stages or not.  Convince me that we don't.

Sure,

This is really a question with two parts, the first part is easy as it
only concerns only this patch.  I think your real question is the
overall reasoning behind this preliminary patch and its followups.

First a little background:

All of our of score of helper generator programs are designed to be run
on the build machine during the GCC build process.  They do not they
serve any useful purpose besides building the compiler and in
particular are not meant to be installed on the host's computer.

Their main purpose is to make a GCC developer life easier by creating a
new host and target specific source file on the fly which will be
linked into the rest of GCC.  The alternative would be to having a
source of hundreds of host and target variations of the same basic
backend which would be a nightmare.

Now to answer your question as it pertains to this patch:

This patch just changes the fact that those [ch] files generated by the
above mention helper programs are deleted after each stage.

The target rules for the insn-* (and the rest of the generated [ch]
files) currently were created in spite of this fact.  Instead of (for
example) insn-attrtab.c depending on directly on genattrtab, it instead
use the well known technique of indirect dependencies via a stamp file
named s-attrtab.  The rules for creating that s-attrtab file run 
genattrtab to output the file into a temporary file and move-if-change
it back to the original.  In a normal build that move-if-change will
not do anything since the generated file gets deleted each stage, so
that indirection may seem pointless.  But it isn't pointless as having
the stamp file does stop a complete rebuild of all the insn-*.o, which
in turn would require a complete rebuild of everything, if one were to
simply touch the .md and rerun make.

All this particular patch does is leave the generated [ch] files in the
new stage.  The target rules will still force genattrtab and it
brethren to be run and output its temporary file.  This file will get
compared to the now undeleted file, which since the generator program
is still being given the same inputs should always be the same.  If it
is the same then the timestamp on the insn-*.c file will remain the
same as when it was run in stage1.  If for some reason it it isn't
identical then the new insn-*.c will have the timestamp of the current
time.

Of course, since all of the *.o files are deleted between stages,
regardless of that insn-*.[ch] file's timestamp (or whether it is in
identical to the original), it will still have to be recompiled by the
new stage1/xgcc to output a fresh insn-*.o file.

Which means that this patch can never cause any problem as at most it
will mean a few dozen timestamps of [ch] files are set to an earlier
time.

So given that explanation, is this particular patch acceptable for
installation?

----

Now for what I'm guessing is your real question, what my overall goal
that this patch sets up and moreover why is it safe?

First of all, I've checked and the input files that each of the
generator programs is required to process are invariant through each
stage.  For example: on i386 genattrtab always processes
$(srcdir)/config/i386/i386.md which will not change stage to stage.

Now, since the generator programs use straight portable C90, I
hypothesize that no matter which of a build machine's C90 compliant
compilers it was compiled under, the resultant program, given the same
inputs should produce the same textfile output.  Clearly, given the
reasons behind having helper generator programs, this is assumed to be
the case by GCC developers.

So if the outputs are not the same then there a bug with either with a)
the build compiler or b) our newly built compiler.  

If it is with a) the build compiler, then it is doubtful that the
resultant stage1 compiler would work at all, so the point would be
moot.

If the difference was due to different due to a bug in b) our stage1
compiler then it is also highly improbable that since we would now be
giving the compiler a buggy source file the resultant stage2 compiler
will be functional enough to create an identical stage3, so we will get
 a bootstrap comparison.  If not one would hope we would pick up that
particular bug in the testsuite.

This is what happens now.

But lets say we don't regenerate those insn-* source files each time,
since they are supposed to be identical at each stage.

If the hypothetical bug from above is present in a) the build compiler,
then obviously the same thing happens and the stage1 compiler fails a
miserable death.

But if that bug were to occur in b) our stage1/compiler then since our
compiler is now attempting to compile the correct insn-*.[ch] source
file and is ever so slightly more likely to be able to produce a
functional complete bootstrap (if and only if that bug ONLY occurs from
some sequence of code present in the gen* files).

But that bug SHOULD still show up in the testsuite.  If not then
clearly it would show up the first time somebody attempts to use the
newly bootstrapped GCC compiler to create another (potentially cross)
compiler.

Though I wouldn't recommend it, if somebody was truly concerned about
missing this hypothetical bug then we could make the generator files
part of the testsuite and check their output against the file made
during bootstrap during a make check.

So what is my impetus to slightly reduce the self-checks within a GCC
bootstrap.

Its that even with --disable-checking, genattrtab takes 20 minutes to
generate an identical insn-attrtab.c file in each stage on my iMac. 
Eliminating this redundant step will shave 40 minutes off of a
bootstrap cycle.  I think that alone would make it a worth the
minuscule additional risk.

Also note that I am clearly *not* proposing that we don't recompile the
insn-*.c files into their resultant insn-*.o files at each stage.

Kelley Cook


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]