Article: AMD's Mobile Strategy
By: Michael S (already5chosen.delete@this.yahoo.com), December 18, 2011 7:25 am
Room: Moderated Discussions
Eugene Nalimov (enal@google.dot.com) on 12/16/11 wrote:
---------------------------
>Wilco (Wilco.Dijkstra@ntlworld.com) on 12/16/11 wrote:
>---------------------------
>>[...]
>
>>>x86 instructions do more.
>
>>No, on average they do less. Nobody cares what the most
>>complex instructions can do if they never get used by the compiler.
>>And x86 instructions are just not a good fit for the code that most
>>people write.
>
>That could be true in the past, but starting from past-Pentium4 compilers are emitting
>complex code again. At least Visual C does that. I worked in the Visual C compiler
>back-end for lot of years, and have first-hand knowledge.
>
>Several years ago x86 Visual C back-end still tried to emit code that would work
>reasonable well on Pentium 4, but x64 Visual C fully used abilities of Opterons
>and post-Pentium 4 CPUs.
> Last work I did at the Visual C was to share some of those
>optimizations with x86-targeting back-end.
>
Why post-Pentium 4?
All pre-Pentium-M Intel CPUs starting from i486 and, may be, even from i386 prefer, as general code generation strategy, code that consists of minimal # of uOps.
Now, when the number of uOps is equal between alternatives, i386 would generally prefer variant that minimizes # of x86 instructions, i486 and Pentium4 mostly don't care, P5 likes variants that maximize pairing and PPro/PII/PIII like 3-1-1 patterns.
So, I'd say that RISC-like code generation is most useful for P5 and P6. Pentium4, on the other hand, handles load-op and load-op-store instructions no better and no worse than equivalent 2 or 3 instr. RISC-like sequences. So, I'd expect from Pentium4-oriented compiler to emit such sequences opportunistically in order to improve code density.
---------------------------
>Wilco (Wilco.Dijkstra@ntlworld.com) on 12/16/11 wrote:
>---------------------------
>>[...]
>
>>>x86 instructions do more.
>
>>No, on average they do less. Nobody cares what the most
>>complex instructions can do if they never get used by the compiler.
>>And x86 instructions are just not a good fit for the code that most
>>people write.
>
>That could be true in the past, but starting from past-Pentium4 compilers are emitting
>complex code again. At least Visual C does that. I worked in the Visual C compiler
>back-end for lot of years, and have first-hand knowledge.
>
>Several years ago x86 Visual C back-end still tried to emit code that would work
>reasonable well on Pentium 4, but x64 Visual C fully used abilities of Opterons
>and post-Pentium 4 CPUs.
> Last work I did at the Visual C was to share some of those
>optimizations with x86-targeting back-end.
>
Why post-Pentium 4?
All pre-Pentium-M Intel CPUs starting from i486 and, may be, even from i386 prefer, as general code generation strategy, code that consists of minimal # of uOps.
Now, when the number of uOps is equal between alternatives, i386 would generally prefer variant that minimizes # of x86 instructions, i486 and Pentium4 mostly don't care, P5 likes variants that maximize pairing and PPro/PII/PIII like 3-1-1 patterns.
So, I'd say that RISC-like code generation is most useful for P5 and P6. Pentium4, on the other hand, handles load-op and load-op-store instructions no better and no worse than equivalent 2 or 3 instr. RISC-like sequences. So, I'd expect from Pentium4-oriented compiler to emit such sequences opportunistically in order to improve code density.