[LLVMdev] [Proposal] function attribute to reduce emission of vzeroupper instructions

[Gao, Yunzhong]

Hi all,

I would like to find out whether anyone will find it useful to add an x86-
specific calling convention for reducing emission of vzeroupper instructions.

Current implementation:
vzeroupper is inserted to any functions that use AVX instructions. The
insertion points are:
1) before a call instruction;
2) before a return instruction;

Background:
vzeroupper is an AVX instruction; it is inserted to avoid performance penalty
when transitioning between x86 AVX mode and legacy SSE mode, e.g., when an
AVX function calls a SSE function. However, vzeroupper is a slow instruction; it
adds to register pressure and hurts performance for AVX-to-AVX calls.

My proposal:
1) (LLVM part) Add an x86-specific calling convention to the LLVM IR which
specifies that an external function will be compiled with AVX support and its
function definition does not use any legacy SSE instructions, e.g.,
  declare x86_avxcc i32 @foo()

2) (Clang part) Add a function attribute to the clang front-end which specifies
this calling convention, e.g.,
  extern int foo() __attribute__((avx));
Function definitions in a translation unit compiled with -mavx architecture will
implicitly have this attribute.

Benefits:
No vzeroupper is needed before calling a function with this avx attribute, e.g.,

  extern int foo() __attribute__((avx));
  void bar() {
    ...
    // some AVX instruction
    ...
    // no vzeroupper is needed before the call instruction
    foo();
    ...
    // still needs a vzeroupper before the return instruction
  }

Reference:
A few months ago, I submitted a proposal for improving vzeroupper optimization
strategy by changing the default code-emission strategy. The proposal was rejected
on the ground that it would cause problems for existing operating systems.
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September/065720.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131219/8b3d810e/attachment.html>