Hi,

We have two ports which support pipeline modelling (--final-insn-count, 
--trace-count) combined with use of --gprof=<file>,cycles=1 in order to 
obtain cycle accurate profiles of the applications being simulated. Our 
clients have complained about the poor performance of SID when using 
these options. The poor performance is mainly due to the following factors:

o The gprof component is a "regular" client of the target scheduler when 
in cycle mode.
o It is necessary to use --insn-count=1 in order to obtain accurate 
samples when using --gprof=<file>,cycles=n. Otherwise the gprof 
component is not triggered after the given number of cycles.

These combine to slow the simulation because each simulated cycle 
requires one entire target scheduler iteration. Also, the gprof 
component's "sample" pin is driven once per simulated cycle.

By making two simple changes, I was able to improve the performance of 
SID by 30% in this situation.

1) Have the cpu component perform gprof sampling directly.
2) Allow a given number of cycles to be driven on the gprof component's 
"sample" pin.

Change number 1 removes the requirement of using --insn-count=1. Gprof 
sampling is now done by the cpu component in step_pin_handler and in 
stop_after_insns_p.

Change number 2 allows several samples to be accumulated at the same pc 
(when there is some kind of stall due to latency), eliminating the need 
to drive the "sample" pin once per simulated cycle. This dramatically 
reduces the number of times the pin is driven during a typical simulation.

These changes also fix a couple of "bugs" in that the gprof option 
wasn't working as advertised (when --help is specified) since

o More samples would be taken than expected in insn-count mode if the 
cpu was yielded
o Fewer samples than expected would be taken in cycle mode if 
--insn-count=1 was not used.

The correct number of samples is now taken in all situations.

I've committed the attached patch which implements these changes. Tested 
on two internal ports which support --gprof. Judging from the lack of 
calls to cg_profile*, no other ports are using this feature.

Dave