Re: User directed Function Multiversioning via Function Overloading (issue5752064)

[Sriraman Tallam <tmsriram at google dot com>]

Hi Jason,

   I have created a new patch to use target hooks for all the
functionality and make the front-end just call the target hooks at the
appropriate places. This is more like what you suggested in a previous
mail. In particular, target hooks address the following questions:

* Determine if two function decls with the same signature are versions.
* Determine the new assembler name of a function version.
* Generate the dispatcher function for a set of function versions.
* Compare versions to see if one has a higher priority over the other.

Patch attached and also available for review at:

http://codereview.appspot.com/5752064/

Hope this is more along the lines of what you had in mind, please let
me know what you think.

Thanks,
-Sri.


On Mon, Jul 30, 2012 at 12:01 PM, Sriraman Tallam <tmsriram@google.com> wrote:
> On Thu, Jul 19, 2012 at 1:39 PM, Jason Merrill <jason@redhat.com> wrote:
>>
>> On 07/10/2012 03:14 PM, Sriraman Tallam wrote:
>>>
>>> I am using the questions you asked previously
>>> to explain how I solved each of them. When working on this patch, these
>>> are the exact questions I had and tried to address it.
>>>
>>> * Does this attribute affect a function signature?
>>>
>>> The function signature should be changed when there is more than one
>>> definition/declaration of foo distinguished by unique target attributes.
>>
>> >[...]
>>
>> I agree.  I was trying to suggest that these questions are what the front end needs to care about, not about versioning specifically.  If these questions are turned into target hooks, all of the logic specific to versioning can be contained in the target.
>>
>> My only question intended to be answered by humans is, do people think moving the versioning logic behind more generic target hooks is worthwhile?
>
> I have  some comments related
>
> For the example below,
>
> // Default version.
> int foo ()
> {
>   .....
> }
>
> // Version  XXX feature supported by Target ABC.
> int foo __attribute__ ((target ("XXX")))
> {
>    ....
> }
>
> How should the second version of foo be treated for targets where
> feature XXX is not supported? Right now, I am working on having my
> patch completely ignore such function versions when compiled for
> targets that do not understand the attribute. I could move this check
> into a generic target hook so that a function definition that does not
> make sense for the current target is ignored.
>
> Also, currently the patch uses target hooks to do the following:
>
> - Find if a particular version can be called directly, rather than go
> through the dispatcher.
> - Determine what the dispatcher body should be.
> - Determining the order in which function versions must be dispatched.
>
> I do not have a strong opinion on whether the entire logic should be
> based on target hooks.
>
> Thanks,
> -Sri.
>
>>
>>
>>
>> Jason

Attachment: mv_fe_patch_new.txt
Description: Text document