[LLVMdev] Proposal to improve vzeroupper optimization strategy

Eli Friedman eli.friedman at gmail.com
Thu Sep 19 12:30:32 PDT 2013


On Thu, Sep 19, 2013 at 11:53 AM, Gao, Yunzhong <
yunzhong_gao at playstation.sony.com> wrote:

> Hi all,
>
> I would like to make a proposal about changing the optimization strategy
> regarding when to insert a vzeroupper instruction in the x86 backend.
>
> 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;
>
> Rationale:
> vzeroupper is an AVX instruction; it is inserted to avoid performance
> penalty
> when switching between x86 AVX mode and SSE mode, e.g., when an AVX
> function
> calls a SSE function.
>
> My proposal:
> Default to not insert vzeroupper instruction unless a function is using
> legacy
> SSE instructions. By a legacy SSE instruction, I mean any vector
> instructions
> that do not have a v- prefix, write XMM register but not YMM register. If a
> legacy SSE instruction is spotted, then insert a vzeroupper instruction:
> 1) before a call instruction;
> 2) before a return instruction;
>

This is essentially equivalent to "don't insert vzeroupper anywhere", as
far as I can tell.  (The case of SSE instructions without a v- prefixed
equivalent is rare enough we can separate it from this discussion.)

The reason we need vzeroupper in the first place is because we can't assume
other functions won't use legacy SSE instructions; for example, on most
systems, calling sin() will use legacy SSE instructions.  I mean, if you
can make some unusual guarantee about your platform, it might make sense to
disable vzeroupper generation in general, but it simply doesn't make sense
on most platforms.

If you want a mechanism to disable vzeroupper generation for particular
function calls, that might make sense...

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130919/2b27d70f/attachment.html>


More information about the llvm-dev mailing list