Re: An unusual Performance approach using Synthetic registers

[Tom Lord <lord at emf dot net>]

       Well most certainly you should not get trapped into a situation
       where CSE values *must* live in registers, but that's not a
       problem. Remember that "retrieving from memory" is *EXACTLY*
       the same code sequence as reading a synthetic register,
       assuming both are on the current stack frame.

Two replies:

1) I don't fully understand why synthregs aren't a common area rather
   than part of stack frames.  A common area _adds_ code to
   save/restore synthregs -- but it also increases the number and
   frequency of references to synthregs.  I don't think L1 is the only
   cache that can be used better by synthregs.


2) Same code sequence (or "worse"), yes.  Same cache interaction, no.




   > It might eventually lead to some hw advances: give synthregs with
   > absolute locations cache preference.  Or, if synthregs are on the
   > stack, give locations near the frame pointer cache preference (or is
   > that done already?).

   I don't see that as a good idea at all. The stack frame indeed will
   almost always be in cache with current designs, and locking cache
   seems a bad idea.

If you're right -- then storing additional non-intermediate values
on the stack (as stack-based synthregs) may very well be a win.

If I'm right, then the net effect of the proposed HW changes is to
bump the number of registers, but to have some registers accessed by 
shorter code sequences than others.

Either way, synthregs (plausibly at least) wins.

       Once again, I would just love to see one (1) example of what is
       being talked about here. Let's see a small kernel in source,
       the current GCC code being generated, and the amazing improved
       code that can be generated with synthetic registers (which are
       nothing more than local memory locations). At this stage I
       really can't imagine such an example, so, assuming this is a
       failure of my imagination (I am not the only one with this
       handicap), please enlighten with one convincing example :-)
       

I'll mostly wimp out for now and hope ja_walker@earthlink.net does
this in detail.

But, sketchingly, let's think of a function that manipulates a dozen
C++ objects, each with a vtable.  It also manipulates some fields in
each object.  The vtable pointers are going to be used lots of times --
each field, just once.  (Maybe the fields are array elements and 
we're talking about a loop here.)

I can't fit all those vtable pointers in regs, but I can fit them in
synthregs.  Do agree that the reg allocator, applied to synthregs,
will keep those vtable pointers in synthregs?

So now the generated code (looking just at the instruction count) with
synthregs will be slightly _worse_ than the code without synthregs --
but if the synthregs really do wind up with noticably better cache
performance, it'll run faster.

Another way to look at this with a slightly longer term perspective is
that synthregs improve locality at a slight cost in instruction count.


-t