On Thu, Jul 19, 2012 at 1:39 PM, Jason Merrill <ja...@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
