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

[Eric Christopher 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 <
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/6977b1fc/attachment.html>