This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 3/3] Speed up genattrtab
>> write_attr_set: Don't update known_true based on previous cases.
>>
>> Updating it is very costly. Not updating it does not result in many
>> changes in the generated code.
>
> It does for some targets, and worse ...
>
>> Also, GCC should be able to do (most of) this optimisation by itself,
>
> ... this isn't the case very often. You'd better check compile times for
> some large routines on several architectures to be sure not to introduce
> compile time regressions for improving bootstrap times.
Sure, creating any real regressions in the compiler itself
wouldn't be a good thing. I'm not _that_ stupid. :-)
Here are statistics for insn-attrtab.[co] (cross from
an AMD64 Linux system):
| insn-attrtab.c | insn-attrtab.o
| # lines | size of .text
| old new | old new
----------------------------------------------
arm | 138102 | 159799 | 477648 | 480632
mips | 83843 | 85221 | 399161 | 400073
powerpc | 80368 | 80825 | 360321 | 360553
sparc | 18519 | 18975 | 129081 | 129129
i386 | 158417 | 164172 | 1154722 | 1171404
----------------------------------------------
parisc | 13068 | 13180 | 97967 | 98575
ia64 | 15078 | 15134 | 100996 | 101028
s390 | 23601 | 24016 | 124635 | 124859
----------------------------------------------
alpha | 7147 | 7147 | 44934 | 44934
avr32 | 2657 | 2657 | 25265 | 25265
blackfin | 2813 | 2849 | 30652 | 30820
cris | 2529 | 2529 | 19124 | 19124
frv | 14060 | 14080 | 68493 | 68595
h8300 | 2180 | 2222 | 21151 | 21191
m32r | 2464 | 2532 | 20004 | 20052
m68k | 89072 | 89158 | 559464 | 559877
mn10300 | 416 | 416 | 2162 | 2162
score | 1252 | 1252 | 19296 | 19296
sh | 14393 | 14777 | 126866 | 127122
xtensa | 757 | 797 | 10121 | 10217
arm has a pretty big source code increase, but it's
all silly stuff like if ((64) == (64)) and it
doesn't actually increase the binary size much. i386
has the biggest actual size increase unfortunately,
but it's only 1.5% as well.
I'll run some timings of the resulting compilers; do
you have some prefered source files to test on?
Segher