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: [vta,vta4.3,trunk?] introduce -fcompare-debug


On Jun  3, 2009, Richard Henderson <rth@redhat.com> wrote:

>> +	      INSN_UID (insn) = 0;
>> +
>> +	}

> Watch the spurious newlines.  There are quite a few.

Oops.  Thanks, will fix.

>> +int compare_debug;
>> +int compare_debug_second;

> There's very little commentary added anywhere in gcc.c.
> What do the different values {-1,0,1,2,3} mean for compare_debug?

I'll add comments, if I can still figure out what they stand for :-)

>> +      const char *gcd = getenv ("GCC_COMPARE_DEBUG");

> I'm not thrilled with the use of environment variables here, but
> the description of its use with -fcompare-debug-not-overridden makes
> some sense.

Yeah, I can't say I'm fond of environment variables either, but this
proved to be quite useful for running tests and builds with
-fcompare-debug when applications didn't obey CFLAGS or somesuch
consistently.

> Surely some subroutines are warrented here.

Oh, come on, you don't like spaghetti? :-)

Will fix.

> With the file comparison, surely we can speed this up a bit
> by examining file sizes first, mmaping the files and using
> memcmp, or even by execing cmp.

Yeah, I guess we could, although stat, mmap, exec, aren't exactly in the
portable feature set that gcc relies on.  I didn't think this warranted
much concern about performance.  It's not like people are going to use
-fcompare-debug all the time, unless we make it part of regular testing.

> Is there a way to have the compiler dump the final_insns file
> without actually doing the comparison within the driver?

-fdump-final-insns, added in this patch too, does that.

> I'm thinking of the usage case where we compile stage2 without debug
> info, and stage3 with debug info, and compare the two stages via their
> dump files

Clever!  We already have BUILD_CONFIG=bootstrap-debug, that does that
comparing object files (minus debug sections) rather than final RTL
dumps, but it would be definitely nice to be able to save on the
recompiles in stage3 due to -fcompare-debug.  I'll implement that.

Of course, for target libraries, where a big chunk of the bootstrap time
goes, -fcompare-debug will still make a difference (for better and for
worse), for we normally build them just once (save for bootstrap4).

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer


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