Re: Function Multiversioning Usability.

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

The gist of previous discussion is to use function overloading instead
of exposing underlying implementation such as builtin_dispatch to the
user. This new refined proposal has not changed in that, but is more
elaborate on various use cases which has been carefully thought out.
Please be specific on which part needs to improvement.

Thanks,

David

On Wed, Aug 17, 2011 at 12:29 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Aug 16, 2011 at 10: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?
>
> Please focus on one mechanism and re-use existing facilities as much as
> possible. ?Thus, see the old discussion where we settled on overloading
> with either using the existing target attribute or a selector function.
>
> I don't see any benefit repeating the discussions here.
>
> Richard.
>
>> Thanks,
>> -Sri.
>>
>