Re: [001/nnn] poly_int: add poly-int.h

[Richard Sandiford <richard dot sandiford at linaro dot org>]

Jeff Law <law@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