This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: An unusual Performance approach using Synthetic registers


> So, with synthetic registers, some values that are not intermediates 
> can be retained (in synthetic registers).  Without synthetic
> registers, the next time those values are used, they have to be 
> fetched from (non-special) memory.

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. 

> 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.

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 :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]