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

Reid Kleckner rnk at google.com
Thu Dec 19 12:36:01 PST 2013


On Thu, Dec 19, 2013 at 12:14 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> On 19 December 2013 14:31, Gao, Yunzhong
> <yunzhong_gao at playstation.sony.com> wrote:
> > 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()
>
> I would suggest using metadata instead. The reasons are:
>
> * It could be applied to functions with different calling conventions.
> For example, on windows we would probably want to do this to thiscall
> (methods) too.
> * It the metadata is dropped, we would just produced slower but still
> correct code (calls vzeroupper).
>

Maybe a target-specific attribute instead?  It would still apply to all
CCs, but would never be dropped.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131219/83099eb2/attachment.html>


More information about the llvm-dev mailing list