Re: Function Multiversioning Usability.

[Xinliang David Li <davidxl at google dot com>]

The specifications should apply to virtual member functions too --
though the underlying implementation for MVed virtual functions and
virtual calls can be quite different.

David

On Tue, Aug 16, 2011 at 1:37 PM, Sriraman Tallam <tmsriram@google.com> wrote:
> Hi,
>
> ?I am working on supporting function multi-versioning in GCC and here
> is a write-up on its usability.
>
> Multiversioning Usability
> ====================
>
> For a simple motivating example,
>
> int
> find_popcount(unsigned int i)
> {
> ?return __builtin_popcount(i);
> }
>
> Currently, compiling this with -mpopcnt will result in the “popcnt”
> instruction being used and otherwise call a built-in generic
> implementation. It is desirable to have two versions of this function
> so that it can be run both on targets that support the popcnt insn and
> those that do not.
>
>
> * Case I - User Guided Versioning where only one function body is
> provided by the user.
>
> This case addresses a use where the user wants multi-versioning but
> provides only one function body. ?I want to add a new attribute called
> “mversion” which will be used like this:
>
> int __attribute__(mversion(“popcnt”))
> find_popcount(unsigned int i)
> {
> ?return __builtin_popcount(i);
> }
>
> With the attribute, the compiler should understand that it should
> generate two versions for this function. The user makes a call to this
> function like a regular call but the code generated would call the
> appropriate function at run-time based on a check to determine if that
> instruction is supported or not.
>
> The attribute can be scaled to support many versions but allowing a
> comma separated list of values for the mversion attribute. For
> instance, “__attribute__(mversion(“sse3”, “sse4”, ...)) will provide a
> version for each. For N attributes, N clones plus one clone for the
> default case will have to be generated by the compiler. The arguments
> to the "mversion" attribute will be similar to the arguments supported
> by the "target" attribute.
>
> This attribute is useful if the same source is going to be used to
> generate the different versions. If this has to be done manually, the
> user has to duplicate the body of the function and specify a target
> attribute of “popcnt” on one clone. Then, the user has to use
> something like IFUNC support or manually write code to call the
> appropriate version. All of this will be done automatically by the
> compiler with this new attribute.
>
> * Case II - User Guided Versioning where the function bodies for each
> version differ and is provided by the user.
>
> This case pertains to multi-versioning when the source bodies of the
> two or more versions are different and are provided by the user. Here
> too, I want to use a new attribute, “version”. Now, the user can
> specify versioning intent like this:
>
> int __attribute__((version(“popcnt”))
> find_popcnt(unsigned int i)
> {
> ? // inline assembly of the popcnt instruction, specialized version.
> ?asm(“popcnt ….”);
> }
>
> int
> find_popcnt(unsigned int i)
> {
> ?//generic code for doing this
> ?...
> }
>
> This uses function overloading to specify versions. ?The compiler will
> understand that versioning is requested, since the functions have
> different attributes with "version", and will generate the code to
> execute the right function at run-time. ?The compiler should check for
> the existence of one body without the attribute which will be the
> default version.
>
> * Case III - Versioning is done automatically by the compiler.
>
> I want to add a new compiler flag “-mversion” along the lines of “-m”.
> If the user specifies “-mversion=popcnt” then the compiler will
> automatically create two versions of any function that is impacted by
> the new instruction. The difference between “-m” and “-mversion” will
> be that while “-m” generates only the specialized version, “-mversion”
> will generate both the specialized and the generic versions. ?There is
> no need to explicity mark any function for versioning, no source
> changes.
>
> The compiler will decide if it is beneficial to multi-version a
> function based on heuristics using hotness information, code size
> growth, etc.
>
>
> Runtime support
> ===============
>
> In order for the compiler to generate multi-versioned code, it needs
> to call functions that would test if a particular feature exists or
> not at run-time. For example, IsPopcntSupported() would be one such
> function. I have prepared a patch to do this which adds the runtime
> support in libgcc and supports new builtins to test the various
> features. I will send the patch separately to keep the dicussions
> focused.
>
>
> Thoughts?
>
> Thanks,
> -Sri.
>