• Bruce Carneal (8/8) Jun 07 2022 Would adding clang's *target_clones* attribute be difficult?
• Iain Buclaw (3/11) Jun 07 2022 [For
• kinke (8/9) Jun 07 2022 Hmm, it's apparently not supported in LLVM IR directly; the IR
• Bruce Carneal (3/12) Jun 07 2022 Thanks for checking. I'll look at gcd (thanks Iain) and at
• Bruce Carneal (2/17) Jun 07 2022 Sorry, gdc.
• Johan (8/17) Jun 07 2022 I've looked at this in the past and indeed this will be a lot of

Bruce Carneal <bcarneal gmail.com> writes:

Would adding clang's *target_clones* attribute be difficult?

Apart from the, potentially serious, amount of developer time are 
there good reasons why it should not be added?  Why it could not 
be generalized to dcompute targets?

I have a clunky workaround for CPUs but it seems like 
target_clones could be beneficial.

Thanks again for providing an excellent compiler (that I use 
every day).

Iain Buclaw <ibuclaw gdcproject.org> writes:

On Tuesday, 7 June 2022 at 14:18:11 UTC, Bruce Carneal wrote:
 Would adding clang's *target_clones* attribute be difficult?

 Apart from the, potentially serious, amount of developer time 
 are there good reasons why it should not be added?  Why it 
 could not be generalized to dcompute targets?

 I have a clunky workaround for CPUs but it seems like 
 target_clones could be beneficial.

 Thanks again for providing an excellent compiler (that I use 
 every day).

[For 
reference](https://github.com/gcc-mirror/gcc/blob/2005b9b888eeac078f2524b1521885f4b5453894/libphobos/libdruntime/gcc/attributes.d#L383-L410).

kinke <noone nowhere.com> writes:

On Tuesday, 7 June 2022 at 14:18:11 UTC, Bruce Carneal wrote:
 Would adding clang's *target_clones* attribute be difficult?

Hmm, it's apparently not supported in LLVM IR directly; the IR 
changes for clang are substantial: 
https://cpp.godbolt.org/z/WT56axqj1

So unless the LLVM API provides a helper (mainly generating the 
resolver with its conditions depending on some 
`__cpu_indicator_init()` and `__cpu_model`), it's probably 
difficult indeed.

Bruce Carneal <bcarneal gmail.com> writes:

On Tuesday, 7 June 2022 at 15:50:56 UTC, kinke wrote:
 On Tuesday, 7 June 2022 at 14:18:11 UTC, Bruce Carneal wrote:
 Would adding clang's *target_clones* attribute be difficult?

 Hmm, it's apparently not supported in LLVM IR directly; the IR 
 changes for clang are substantial: 
 https://cpp.godbolt.org/z/WT56axqj1

 So unless the LLVM API provides a helper (mainly generating the 
 resolver with its conditions depending on some 
 `__cpu_indicator_init()` and `__cpu_model`), it's probably 
 difficult indeed.

Thanks for checking.  I'll look at gcd (thanks Iain) and at 
another CT hack that groups and manages the target funcs manually.

Bruce Carneal <bcarneal gmail.com> writes:

On Tuesday, 7 June 2022 at 16:15:03 UTC, Bruce Carneal wrote:
 On Tuesday, 7 June 2022 at 15:50:56 UTC, kinke wrote:
 On Tuesday, 7 June 2022 at 14:18:11 UTC, Bruce Carneal wrote:
 Would adding clang's *target_clones* attribute be difficult?

 Hmm, it's apparently not supported in LLVM IR directly; the IR 
 changes for clang are substantial: 
 https://cpp.godbolt.org/z/WT56axqj1

 So unless the LLVM API provides a helper (mainly generating 
 the resolver with its conditions depending on some 
 `__cpu_indicator_init()` and `__cpu_model`), it's probably 
 difficult indeed.

 Thanks for checking.  I'll look at gcd (thanks Iain) and at 
 another CT hack that groups and manages the target funcs 
 manually.

Sorry, gdc.

Johan <j j.nl> writes:

On Tuesday, 7 June 2022 at 15:50:56 UTC, kinke wrote:
 On Tuesday, 7 June 2022 at 14:18:11 UTC, Bruce Carneal wrote:
 Would adding clang's *target_clones* attribute be difficult?

 Hmm, it's apparently not supported in LLVM IR directly; the IR 
 changes for clang are substantial: 
 https://cpp.godbolt.org/z/WT56axqj1

 So unless the LLVM API provides a helper (mainly generating the 
 resolver with its conditions depending on some 
 `__cpu_indicator_init()` and `__cpu_model`), it's probably 
 difficult indeed.

I've looked at this in the past and indeed this will be a lot of 
work + probably a lot of maintenance work. Unfortunately, the 
LLVM project implementation resides mainly in Clang's code, 
rather than LLVM's. I'd say the first step is within the LLVM 
project to move code to the shared LLVM library, so it's 
available for other frontends (=us).

-Johan