This is the mail archive of the gcc@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] | |
Usually I check code size fo x86/x86_64. If it is bigger then something is going wrong (it might be not true for itanium). It means more insns (and probably performance degradation) and more compile time to process insns (but i think for df generation more insns is only part of slowdown). For df gcc code size is 0.5% bigger.
I am agree, benchmarking is evil. My favorite benchmark is gcc because it is my tool and I work on it. Compilation of gcc from Spec2000 is >12% slower with df including last Paolo's patches (which are a really big improvement).
Interesting enough, 176.gcc has a pretty bad result for runtime too in SPEC2000:
176.gcc 1100 67.8 1622 1100 72.9 1509* 176.gcc 1100 68.1 1614* 1100 72.9 1509 176.gcc 1100 68.8 1600 1100 72.6 1515
By your reasoning, there is some probability that fixing this one performance regression brings dataflow branch into shape for merging into mainline... (even though so much has changed since 2.7.2 which is used in SPEC2000).
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |