[IFUNC] PATCH: Add an ifunc attribute

H.J. Lu hjl.tools@gmail.com
Sun Jun 28 19:40:00 GMT 2009


On Sun, Jun 28, 2009 at 11:13 AM, Richard
Guenther<richard.guenther@gmail.com> wrote:
> On Sun, Jun 28, 2009 at 7:27 PM, H.J. Lu<hjl.tools@gmail.com> wrote:
>> On Sun, Jun 28, 2009 at 10:20 AM, Richard
>> Guenther<richard.guenther@gmail.com> wrote:
>>> On Sun, Jun 28, 2009 at 7:01 PM, H.J. Lu<hjl.tools@gmail.com> wrote:
>>>> On Sun, Jun 28, 2009 at 9:57 AM, Richard
>>>> Guenther<richard.guenther@gmail.com> wrote:
>>>>> On Sun, Jun 28, 2009 at 6:37 PM, H.J. Lu<hjl.tools@gmail.com> wrote:
>>>>>> On Sun, Jun 28, 2009 at 9:17 AM, Richard
>>>>>> Guenther<richard.guenther@gmail.com> wrote:
>>>>>>> On Sun, Jun 28, 2009 at 5:10 PM, H.J. Lu<hongjiu.lu@intel.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Here is a patch to add ifunc attribute, including many testscases
>>>>>>>> in C and C++.  Any comments?
>>>>>>>
>>>>>>> +/* Get the function return type inside function body.  Return a pointer
>>>>>>> +   to the function for IFUNC function.  */
>>>>>>> +
>>>>>>> +static inline tree
>>>>>>> +function_return_type (const_tree decl)
>>>>>>> +{
>>>>>>> +  if (DECL_IS_IFUNC (decl))
>>>>>>> +    return build_pointer_type (TREE_TYPE (decl));
>>>>>>> +  else
>>>>>>> +    return TREE_TYPE (TREE_TYPE (decl));
>>>>>>> +}
>>>>>>>
>>>>>>> that's just ... gross.  Instead adjust the function signature properly.
>>>>>>> Which of course makes your proposal not viable at all.
>>>>>>>
>>>>>>> I think your solution is overdesigned.  Do you really expect so much
>>>>>>> usage that you need to make it easy to use from C++ (easy as in
>>>>>>> not mangle manually)?
>>>>>>>
>>>>>>
>>>>>> I was told that people do want to use ifunc attribute in C++ class.
>>>>>
>>>>> They will be able to.  Just not in a way that is 100% pretty and feels
>>>>> integrated.
>>>>>
>>>>> So what.
>>>>
>>>> There are a dozen C++ ifunc tests on ifunc branch. Can you show
>>>> me what the different C++ syntax looks like with a different ifunc
>>>> attribute approach?
>>>
>>> It's a straight-forward substitution.
>>>
>>> struct Foo {
>>>  int foo1(void);
>>>  int foo(void);
>>> };
>>>
>>> __typeof(&Foo::foo) __attribute__((ifunc))
>>> blah(void) asm("_ZN3Foo3fooEv");
>>
>> User has to mangled the name him/herself. Any change
>> to prototype of foo needs update it by hand.
>>
>>>
>>> __typeof(&Foo::foo) blah(void)
>>> {
>>>  return &Foo::foo1;
>>> }
>>
>> How do you handle
>>
>> class ifunc
>> {
>> private:
>>  int foo1 (int);
>>  int foo2 (float);
>>
>> public:
>>  int foo (int);
>>  int foo (float);
>>  int bar (int);
>>  int bar (float);
>> };
>>
>> int
>> __attribute__ ((ifunc))
>> ifunc::foo (int)
>> {
>>  return &ifunc::foo1;
>> }
>>
>> int
>> __attribute__ ((ifunc))
>> ifunc::foo (float)
>> {
>>  return &ifunc::foo2;
>> }
>>
>> where you have 2 Foo::foo with different parameters?
>
> I don't see the problem here.
>
> typedef int (ifunc::*)(float) x1_t;
> typedef int (ifunc::*)(int) x2_t;
>
> x1_t blabla(void) __attribute__((ifunc)) asm("_ZN5ifunc3fooEf");
> x1_t blabla(void)
> {
>  return &ifunc::foo2;
> }
> ...
>

Some ABIs have the leading underscore in the symbol name.
How does a programmer use asm () portably?

I don't think using asm to change symbol name is usable
for C++. It simply makes it next to impossible to use the
ifunc attribute in C++ class.

-- 
H.J.



More information about the Gcc-patches mailing list