This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [IFUNC] PATCH: Add an ifunc attribute


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;
}
...

Richard.

>
> H.J.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]