Jeff Law <l...@redhat.com> writes: > On 11/09/2017 04:06 AM, Richard Sandiford wrote: > >>> Let me say at the outset that I struggle to comprehend that a few >>> instructions is even a consideration when not optimizing, especially >>> in light of the bug the macro caused that would have been prevented >>> by using a function instead. But... >> >> Many people still build at -O0 though. One of the things I was asked >> for was the time it takes to build stage 2 with an -O0 stage 1 >> (where stage 1 would usually be built by the host compiler). > I suspect folks are concerned about this because it potentially affects > their daily development cycle times. So they're looking to see if the > introduction of the poly types has a significant impact. It's a > legitimate question, particularly for the introduction of low level > infrastructure that potentially gets hit a lot. > > Richard, what were the results of that test (if it's elsewhere in the > thread I'll eventually find it...
On an x86_64 box I got: real: +7% user: +8.6% for building stage2 with an -O0 -g stage1. For aarch64 with the NUM_POLY_INT_COEFFS==2 change it was: real: +17% user: +20% That's obviously not ideal, but C++11 would get rid of some of the inefficiencies, once we can switch to that. You've probably already seen this, but it's compile-time neutral on x86_64 in terms of running a gcc built with --enable-checking=release, within a margin of about [-0.1%, 0.1%]. For aarch64 with NUM_POLY_INT_COEFFS==2, a gcc built with --enable-checking=release is ~1% slower when using -g and ~2% slower with -O2 -g. > I'm just starting to try and make some headway on this kit). Thanks :-) I guess it's going to be a real slog going through them, sorry, even despite the attempt to split them up. Richard
