Help on Instruction Scheduler for UltraSPARC

[Kuriakose Kuruvilla <kuriakose dot kuruvilla at wipro dot com>]

Hi

I am trying to evaluate the performance improvement for an instruction
scheduler for ultraSPARCIIi SPARC-V9 instructions generated on the fly. 
This is targeted for Solaris 2.7.

The scheduler I'm working on seems to correctly reorder code based on
the Grouping Logic rules as suggested by the UltraSPARCIIi User's
Manual.

For example, SLLX uses IEU0 and ADD is a non-specific IEU instruction.
Hence...
         sllx %i2, 2, %i2 ! Group1
         sllx %i3, 2, %i3 ! Group2
         sllx %i4, 2, %i4 ! Group3
         add  %l4, 2, %l4 ! Group4
         add  %l5, 2, %l5 ! Group4
         add  %l6, 2, %l6 ! Group5
would be better scheduled as...
         sllx %i2, 2, %i2 ! Group1
         add  %l4, 2, %l4 ! Group1
         sllx %i3, 2, %i3 ! Group2
         add  %l5, 2, %l5 ! Group2
         sllx %i4, 2, %i4 ! Group3
         add  %l6, 2, %l6 ! Group3
which should yield an improvement of two cycles.

But I do not get the expected performance improvement in my regular test
suites.

So I tried using the Performance Counter Registers (PCR) and the
Performance Instrumentation Counters (PICs) provided by the processor. 
Privileged access to PCR was done through a freely available perfmon
driver.

But this does not seem to be getting me accurate, consistent values when
I tried determining the number of instruction cycles.  Also, the number
of instructions shown by PIC to have executed is not exactly the number
of instructions that were timed, but is also dependent on where the
instructions are located in the address space (if the first instruction
timed is the last instruction a block of 8 instructions, aligned at
32-byte boundary, 7 more instructions are added to the counter value
corresponding to "instructions executed".

People I've contacted earlier suggest that the PIC/PCR registers are
broken in some way.

Do you know whether the PIC/PCR registers on the UltraSPARCIIi show
incorrect data?  If so, is this error predictable or not?  If it is
predictably wrong how do we perform error correction in order to make up
for the inaccuracy?

How was the performance improvement of the gcc instruction scheduler
tested on SPARC?  Did the people involved face similar issues?

Any other related information that would be of help would be
appreciated.

Kuriakose