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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Jan 7 16:52:16 PST 2014


> Hi Aaron,
> Many thanks for your feedback!
>
> I do not have any opinion right now on how this attribute should interact with
> the __vectorcall calling convention. I will need to revisit it later.
>
> Regarding the implicit attachment of this attribute, my intention is to only
> imply the avx attribute on function definitions. Since the backend can see what
> instructions are being generated in the callee, it should be able to make smart
> decisions on whether to emit a vzeroupper before the call instruction. In the
> above example, foo() would not implicitly carry the avx attribute because the
> compiler sees only its declaration.

to be clear, in the example

extern void foo(__m256i x);
extern int bar();
void zed(__m256i x) {
  foo(x);
  bar();
  foo(x);
}

we currently produce a vzeroupper before the call to bar and one
before the return. If the attribute is implicitly added only to
definitions, it will only be added to zed. In which case, wouldn't we
need to keep both vzeroupper instructions? The one before bar is
needed because it is missing the attribute. The one before the return
is needed because we don't know what might call zed.

This looks a bit like how -fvisibility=hidden is implemented. That
implementation is extremely complex, so it would be nice to know that
this will not grow in that direction. The issues there are

* The visibility applies to types. This exists so that it is possible
for all data in a class to have a particular visibility. Do you
envision this attribute also being applied to class types to mean "the
entire class is avx"?
* There are complex rules about when a implicit visibility attribute
is active and how to merge implicit and explicit visibilities.

Do you think that with the attribute as proposed the number of
vzeroupper will be low enough (maybe with LTO) that we wouldn't need
to extend it further?

Cheers,
Rafael



More information about the llvm-dev mailing list