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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Dec 24 04:50:06 PST 2013

> In general, I'm not too keen on adding more calling conventions unless
> there's a really powerful need for one from an ABI perspective. This
> sounds more like an optimization than an ABI need.

I think that is the case.

> What's more, I
> worry (a little bit) about confusion that could be caused with the
> __vectorcall calling convention (which we do not currently support,
> but will need to at some point for MSVC compatibility).

What does the __vectorcall does?

> What should happen with this code?
> int foo() __attribute__((avx));
> void bar(int (*fp)()) {
>   int i = fp();
> }
> void baz(void) {
>   bar(foo);
> }
> Based on your description, this code is valid, but not as performant
> as it could be. The vzeroupper would be inserted before fp() is
> called, but there's no incompatibility happening. So I guess this
> feels more like a regular function attribute than a calling
> convention.

It is not a calling convention. The issue is more if it is a type or a
decl attribute. Given that putting the attributes on the function
decls is the simplest and should cover most of the cases, I think we
can probably start with that and revisit if we still see too many
vzeroupper  being inserted. What do you think?

>> Function definitions in a translation unit compiled with -mavx architecture
>> will
>> implicitly have this attribute.
> Can you safely do that? What about code that does uses inline assembly
> to use legacy SSE instructions in a TU compiled with -mavx, for
> instance?

I think it would take a performance penalty, but I don't expect that
to be common.


More information about the cfe-dev mailing list