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).

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.

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.

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.

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