This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [001/nnn] poly_int: add poly-int.h
On 11/13/2017 04:36 PM, Richard Sandiford wrote:
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.
For the purposes of this discussion, what would the numbers look
like if the macro were replaced with the inline function as I
suggested?
What impact on the numbers would having the default ctor actually
initialize the object have? (As opposed to leaving it uninitialized.)
I don't want to make a bigger deal out of this macro than it
already is. Unlike the wide int constructors, it's
an implementation detail that, when correct, almost no-one will
have to worry about. The main reason for my strenuous objections
is not the macro itself but the philosophy that performance,
especially at -O0, should be an overriding consideration. Code
should be safe first and foremost. Otherwise, the few cycles we
might save by writing unsafe but fast code will be wasted in
debugging sessions.
Martin