Re: Sythetic registers: modrm/gas question.

[Michael S. Zick <mszick at goquest dot com>]

On Sunday 05 January 2003 08:17 am, Robert Dewar wrote:
> > Synthregs improve locality at a slight cost in code size.  I agree
> > with ja_walker that the worthiness of that trade-off is an emprical
> > question worth measuring.  I'd go beyond him by saying that in the
> > medium term future, the trade-off almost certainly wins often.
>
> I disagree. In practice references to the local stack frame are nearly
> always in cache. So there is just nothing much to improve. Actually it
> is instruction cache that causes problems more often than data cache,
> and making code larger is almost always a loss (that's way for example
> -O3 frequently slows things down compared with -O2, and in the case of
> Ada, where it is more normal to explicitly control inlining, -O3 is
> almost always worse).
>
> > x86 is a "rapidly" exploding range of physical architectures.
>
> True, but the basic observation above holds for all of them, from the
> 486 onwards.
>
> > "Yeah, well, until you've done the same you've no
> > business talking about the SR proposal"
>
> Gosh, you took the words out of my mouth :-) :-)
>
> Seriously, I do think this needs to be discussed at a detailed level, which
> is why I asked for an example. If we look at a specific example, then we
> can fill in any details that are needed for the example, and not rely on
> everyone having detailed knowledge of the architecture.
>
> By the way, to repeat an idea that I think is definitely worth following up
> on, register renaming plays a very important part in these architectures.
> The Pentium-4 has something like 40 registers (can't remember exact number
> and can't be bothered to look it up :-) Only 8 of these are directly
> nameable, but in a real program, many of these can get used.
>
> I think it would be really interesting to study the issue of taking the
> renaming into account when allocating registers. Consider
>
>    mov ax, mem1
>    add ax, 1
>    mov mem1, ax
>    mov ax, mem2
>    add ax, 2
>    mov mem2, ax
>
> Classical optimization suggests
>
>    mov ax, mem1
>    mov bx, mem2
>    add ax, 1
>    add bx, 1
>    mov mem1, ax
>    mov mem2, bx
>
> so that the two operations can be done in parallel in separate pipelines,
> but in fact the first sequence is better, since register renaming will
> allow the use of two separate pipelines, and you don't use up another
> nameable register, which are what are in very short supply.
>
For certain sure...
Trying to be too smart in the instruction scheduling area will only
result in the compiler designer "shooting himself in the foot" with
some of the modern day processors.

I.E: Using a lot of compiler time, to generate a lot of code, with the
only real effect being defeating the effectiveness of the CPU's
renaming mechanisms.

> The above is just an illustrative example of the kind of thing I am
> talking about here. The devil is in the details (as with the SR proposal
> itself), and you really have to know EXACTLY how the renaming works to
> make sure you generate code that cooperates with it.
>
> I am trying to interest a PhD student to do research in this area :-)
>
Another area for improvement:
Doing reverential pattern, frequency analysis of data over program
flow and then, with knowledge of the data cache size, mapping and
replacement algorithm order and pack the data allocations with
the goal that they are always "cache hot".

>
> There is some work done, but not that much.
I have to strongly disagree with that observation.

Mike