Re: Using a DFA for insn-recog.c

[Richard Sandiford <rdsandiford at googlemail dot com>]

Andi Kleen <andi@firstfloor.org> writes:
> Richard Sandiford <rdsandiford@googlemail.com> writes:
>> I think Mark's point was that the size reductions are not in themselves
>> particularly exciting.  The loadable size of an x86_64-linux-gnu cc1 is
>> about 10M on my machine, so the patch represents a saving of about 1%.
>
> Looking at the total executable size is not very interesting because
> it won't have a direct impact on performance . Some of that code might 
> be never loaded.

But we seem to be talking past each other.  I wasn't suggesting
that reducing the loadable size of cc1 would directly improve
performance (as in, compiler speed).  At least not in cases
where no swap space is needed.

> What would be more interesting is the working set size of the compiler
> that has to be loaded into the CPU's caches.
>
> You could probably determine this by comparing d/icache miss rate
> between your patched and unpatched version for the same
> program. If the miss rate is better with your version it's a win.

But this goes back to what I said upthread:

    (I wondered about using detailed profiling tools, but if that's the
    only way to measure the result, would any improvement really count
    for much?)

In other words, if the only way to measure the impact of the patch
is by pointing at miss rates, the patch does not justify itself from
a performance perspective.  A necessary (but not sufficient) condition
for it to be justified from a performance perspective is that a user
would notice the difference for a particular testcase.

Richard