[cfe-dev] Setting a FunctionDecl as 'uncallable':
Eric Christopher via cfe-dev
cfe-dev at lists.llvm.org
Thu Jul 6 12:55:41 PDT 2017
On Thu, Jul 6, 2017 at 12:53 PM Keane, Erich <erich.keane at intel.com> wrote:
>
>
> *From:* Eric Christopher [mailto:echristo at gmail.com]
> *Sent:* Thursday, July 6, 2017 12:48 PM
>
>
> *To:* Keane, Erich <erich.keane at intel.com>; Richard Smith <
> richard at metafoo.co.uk>; Eric Christopher <echristo at google.com>
> *Cc:* Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] Setting a FunctionDecl as 'uncallable':
>
>
>
>
>
> On Thu, Jul 6, 2017 at 12:11 PM Keane, Erich <erich.keane at intel.com>
> 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:
https://gcc.gnu.org/wiki/FunctionMultiVersioning
I just stopped at "create your own dispatch function".
-eric
> -eric
>
>
>
> *From:* Eric Christopher [mailto:echristo at gmail.com]
> *Sent:* Thursday, July 6, 2017 12:02 PM
> *To:* Keane, Erich <erich.keane at intel.com>; Richard Smith <
> richard at metafoo.co.uk>; Eric Christopher <echristo at google.com>
> *Cc:* Clang Dev <cfe-dev at lists.llvm.org>
>
>
> *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 <
> cfe-dev at lists.llvm.org> 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:* metafoo at gmail.com [mailto:metafoo at gmail.com] *On Behalf Of *Richard
> Smith
> *Sent:* Thursday, July 6, 2017 11:41 AM
> *To:* Keane, Erich <erich.keane at intel.com>; Eric Christopher <
> echristo at google.com>
> *Cc:* Clang Dev <cfe-dev at lists.llvm.org>; Reid Kleckner <rnk at google.com>
>
>
> *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" <cfe-dev at lists.llvm.org>
> 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:rnk at google.com]
> *Sent:* Thursday, July 6, 2017 11:25 AM
> *To:* Keane, Erich <erich.keane at intel.com>
> *Cc:* cfe-dev at lists.llvm.org
> *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 <
> cfe-dev at lists.llvm.org> 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
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170706/93feb077/attachment.html>
More information about the cfe-dev
mailing list