Setting a FunctionDecl as 'uncallable':

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev
Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev
My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:
Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev
+echristo This sounds similar to attribute target. Perhaps some of the work there could be reused?

On 6 Jul 2017 11:32 am, "Keane, Erich via cfe-dev" <[hidden email]> wrote:

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev

I’m using the ‘emit’ functionality from attribute-target to get the target-cpu emitted properly, however I hadn’t realized it allowed multiple function definitions.  I’ll look into that one as well.

 

Thanks Richard!

-Erich

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Smith
Sent: Thursday, July 6, 2017 11:41 AM
To: Keane, Erich <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>; Reid Kleckner <[hidden email]>
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

+echristo This sounds similar to attribute target. Perhaps some of the work there could be reused?

 

On 6 Jul 2017 11:32 am, "Keane, Erich via cfe-dev" <[hidden email]> wrote:

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev
It's pretty much exactly attribute target :)

I'll definitely want to know if there are any differences in use between them.

-eric

On Thu, Jul 6, 2017 at 11:43 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

I’m using the ‘emit’ functionality from attribute-target to get the target-cpu emitted properly, however I hadn’t realized it allowed multiple function definitions.  I’ll look into that one as well.

 

Thanks Richard!

-Erich

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Smith
Sent: Thursday, July 6, 2017 11:41 AM
To: Keane, Erich <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>; Reid Kleckner <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

+echristo This sounds similar to attribute target. Perhaps some of the work there could be reused?

 

On 6 Jul 2017 11:32 am, "Keane, Erich via cfe-dev" <[hidden email]> wrote:

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev

The difference as far as I can tell is that the dispatch is done at Load/Runtime.  It checks on “CPUID” to determine which function to call.  As far as I can tell, target simply sends optimization hints to the backend, right?


I think this is intended to be a superset of the ‘target’ functionality.

 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:02 PM
To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

It's pretty much exactly attribute target :)

 

I'll definitely want to know if there are any differences in use between them.

 

-eric

 

On Thu, Jul 6, 2017 at 11:43 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

I’m using the ‘emit’ functionality from attribute-target to get the target-cpu emitted properly, however I hadn’t realized it allowed multiple function definitions.  I’ll look into that one as well.

 

Thanks Richard!

-Erich

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Smith
Sent: Thursday, July 6, 2017 11:41 AM
To: Keane, Erich <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>; Reid Kleckner <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

+echristo This sounds similar to attribute target. Perhaps some of the work there could be reused?

 

On 6 Jul 2017 11:32 am, "Keane, Erich via cfe-dev" <[hidden email]> wrote:

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev


On Thu, Jul 6, 2017 at 12:11 PM Keane, Erich <[hidden email]> wrote:

The difference as far as I can tell is that the dispatch is done at Load/Runtime.  It checks on “CPUID” to determine which function to call.  As far as I can tell, target simply sends optimization hints to the backend, right?



You can set up automagic dispatch using ifunc or the rest of that (they do in gcc), just a lot of that functionality isn't wired up.
 

I think this is intended to be a superset of the ‘target’ functionality.

 


At a function definition level it's exactly the same :)

At any rate, please do keep me on reviews for this. I don't believe the mechanics in general should be any different.

-eric
 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:02 PM
To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

It's pretty much exactly attribute target :)

 

I'll definitely want to know if there are any differences in use between them.

 

-eric

 

On Thu, Jul 6, 2017 at 11:43 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

I’m using the ‘emit’ functionality from attribute-target to get the target-cpu emitted properly, however I hadn’t realized it allowed multiple function definitions.  I’ll look into that one as well.

 

Thanks Richard!

-Erich

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Smith
Sent: Thursday, July 6, 2017 11:41 AM
To: Keane, Erich <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>; Reid Kleckner <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

+echristo This sounds similar to attribute target. Perhaps some of the work there could be reused?

 

On 6 Jul 2017 11:32 am, "Keane, Erich via cfe-dev" <[hidden email]> wrote:

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev

 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:48 PM
To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

 

On Thu, Jul 6, 2017 at 12:11 PM Keane, Erich <[hidden email]> wrote:

The difference as far as I can tell is that the dispatch is done at Load/Runtime.  It checks on “CPUID” to determine which function to call.  As far as I can tell, target simply sends optimization hints to the backend, right?

 

 

You can set up automagic dispatch using ifunc or the rest of that (they do in gcc), just a lot of that functionality isn't wired up.

[Keane, Erich] I’m currently implementing in terms of ifunc, though I’m not sure what you mean here?  Are we missing some functionality of ‘target’ that would make it a lot more similar?

 

I think this is intended to be a superset of the ‘target’ functionality.

 

 

At a function definition level it's exactly the same :)

[Keane, Erich] The difference is that this allows multiple definitions of the same function, which does not seem to be the case in target.  Am I missing something else here? 

 

At any rate, please do keep me on reviews for this. I don't believe the mechanics in general should be any different.

[Keane, Erich] I definitely will!  I was hoping to do ‘in progress’ reviews once I’m confident with the direction.

 

-eric

 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:02 PM
To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

It's pretty much exactly attribute target :)

 

I'll definitely want to know if there are any differences in use between them.

 

-eric

 

On Thu, Jul 6, 2017 at 11:43 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

I’m using the ‘emit’ functionality from attribute-target to get the target-cpu emitted properly, however I hadn’t realized it allowed multiple function definitions.  I’ll look into that one as well.

 

Thanks Richard!

-Erich

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Smith
Sent: Thursday, July 6, 2017 11:41 AM
To: Keane, Erich <
[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <
[hidden email]>; Reid Kleckner <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

+echristo This sounds similar to attribute target. Perhaps some of the work there could be reused?

 

On 6 Jul 2017 11:32 am, "Keane, Erich via cfe-dev" <[hidden email]> wrote:

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev


On Thu, Jul 6, 2017 at 12:53 PM Keane, Erich <[hidden email]> wrote:

 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:48 PM


To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

 

On Thu, Jul 6, 2017 at 12:11 PM Keane, Erich <[hidden email]> wrote:

The difference as far as I can tell is that the dispatch is done at Load/Runtime.  It checks on “CPUID” to determine which function to call.  As far as I can tell, target simply sends optimization hints to the backend, right?

 

 

You can set up automagic dispatch using ifunc or the rest of that (they do in gcc), just a lot of that functionality isn't wired up.

[Keane, Erich] I’m currently implementing in terms of ifunc, though I’m not sure what you mean here?  Are we missing some functionality of ‘target’ that would make it a lot more similar?

 

I think this is intended to be a superset of the ‘target’ functionality.

 

 

At a function definition level it's exactly the same :)

[Keane, Erich] The difference is that this allows multiple definitions of the same function, which does not seem to be the case in target.  Am I missing something else here? 

 

At any rate, please do keep me on reviews for this. I don't believe the mechanics in general should be any different.

[Keane, Erich] I definitely will!  I was hoping to do ‘in progress’ reviews once I’m confident with the direction.

 


FWIW here's what our support is based upon:


I just stopped at "create your own dispatch function".

-eric


 

-eric

 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:02 PM
To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

It's pretty much exactly attribute target :)

 

I'll definitely want to know if there are any differences in use between them.

 

-eric

 

On Thu, Jul 6, 2017 at 11:43 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

I’m using the ‘emit’ functionality from attribute-target to get the target-cpu emitted properly, however I hadn’t realized it allowed multiple function definitions.  I’ll look into that one as well.

 

Thanks Richard!

-Erich

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Smith
Sent: Thursday, July 6, 2017 11:41 AM
To: Keane, Erich <
[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <
[hidden email]>; Reid Kleckner <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

+echristo This sounds similar to attribute target. Perhaps some of the work there could be reused?

 

On 6 Jul 2017 11:32 am, "Keane, Erich via cfe-dev" <[hidden email]> wrote:

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Setting a FunctionDecl as 'uncallable':

Xin Wang via cfe-dev

Thanks for the link!  I definitely see that this is very similar then!  I DID try the first example on your link, and it fails because of ‘redefinition of foo’.

 

It actually seems that this cpu_dispatch/cpu_specific is perhaps even a sub-set of GCC’s target (since it only handles the ‘arch=’ tests).  The only real difference after that will be the linked-names, but perhaps that is something acceptable to us as well (or that could be kept internal).

 

Perhaps my best goal here would be instead to help you (or, have you guide me) to implement ‘target’ the rest of the way(IFunc, multiple defs, changing the name-mangling), then create cpu_dispatch/cpu_specific as an alias for ‘target’. 

 

Thanks,

Erich

 

 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:56 PM
To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

 

On Thu, Jul 6, 2017 at 12:53 PM Keane, Erich <[hidden email]> wrote:

 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:48 PM


To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

 

On Thu, Jul 6, 2017 at 12:11 PM Keane, Erich <[hidden email]> wrote:

The difference as far as I can tell is that the dispatch is done at Load/Runtime.  It checks on “CPUID” to determine which function to call.  As far as I can tell, target simply sends optimization hints to the backend, right?

 

 

You can set up automagic dispatch using ifunc or the rest of that (they do in gcc), just a lot of that functionality isn't wired up.

[Keane, Erich] I’m currently implementing in terms of ifunc, though I’m not sure what you mean here?  Are we missing some functionality of ‘target’ that would make it a lot more similar?

 

I think this is intended to be a superset of the ‘target’ functionality.

 

 

At a function definition level it's exactly the same :)

[Keane, Erich] The difference is that this allows multiple definitions of the same function, which does not seem to be the case in target.  Am I missing something else here? 

 

At any rate, please do keep me on reviews for this. I don't believe the mechanics in general should be any different.

[Keane, Erich] I definitely will!  I was hoping to do ‘in progress’ reviews once I’m confident with the direction.

 

 

FWIW here's what our support is based upon:

 

 

I just stopped at "create your own dispatch function".

 

-eric

 

 

 

-eric

 

From: Eric Christopher [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 12:02 PM
To: Keane, Erich <[hidden email]>; Richard Smith <[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

It's pretty much exactly attribute target :)

 

I'll definitely want to know if there are any differences in use between them.

 

-eric

 

On Thu, Jul 6, 2017 at 11:43 AM Keane, Erich via cfe-dev <[hidden email]> wrote:

I’m using the ‘emit’ functionality from attribute-target to get the target-cpu emitted properly, however I hadn’t realized it allowed multiple function definitions.  I’ll look into that one as well.

 

Thanks Richard!

-Erich

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Smith
Sent: Thursday, July 6, 2017 11:41 AM
To: Keane, Erich <
[hidden email]>; Eric Christopher <[hidden email]>
Cc: Clang Dev <
[hidden email]>; Reid Kleckner <[hidden email]>


Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

+echristo This sounds similar to attribute target. Perhaps some of the work there could be reused?

 

On 6 Jul 2017 11:32 am, "Keane, Erich via cfe-dev" <[hidden email]> wrote:

Thanks!  I’ll look into enable_if and others.

 

To spoil my RFC:

__attribute__((cpu_specific(atom)))

void foo(){} // atom specific impl

__attribute__((cpu_specific(p3)))

void foo(){} // p3 specific impl

__attribute__((cpu_dispatch(atom, p3)))

void foo(){}; // dispatch function.

 

Each ‘foo’ implementation is emitted with different name mangling.  They are generally ALL considered the same function, Function Pointers, references, etc will all be to the ‘dispatch’ version of the function.


The dispatch function will be implemented in terms of an iFunc.

 

-Erich

 

 

From: Reid Kleckner [mailto:[hidden email]]
Sent: Thursday, July 6, 2017 11:25 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':

 

My first guess would be that you want to modify overload resolution. I think the CUDA host/device attributes are involved there. You can also look at the implementation of __attribute__((enable_if)) as well.

 

However, do we really need a FunctionDecl for every subtarget specialization? How does a user trigger specialization? Can they do something like take a specialization and instantiate a class template with it?

 

On Thu, Jul 6, 2017 at 9:31 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi all-
I'm working on an attribute implementation (RFC coming once I get a better idea about the implementation details, cpu_dispatch/cpu_specific from ICC) that permits multiple definitions of a function.  All definitions of the function ARE emitted, however with different name-mangling.  1 version of the function keeps the normal name-mangling/linking, so all call-expressions should call THAT one.

My question is: Is there a way to mark a FunctionDecl as 'don't find me in lookup' such that it never ends up being a "Callee"?  Or should I be figuring out how to change the lookup-results here?

Thanks,
Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...