Yangyu Chen <c...@cyyself.name> writes:
>> On 6 May 2025, at 17:49, Alfie Richards <alfie.richa...@arm.com> wrote:
>>
>> On 06/05/2025 09:36, Yangyu Chen wrote:
>>>> On 6 May 2025, at 16:01, Alfie Richards <alfie.richa...@arm.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I like this idea. I have a couple thoughts to add.
>>>>
>>>> On 05/05/2025 09:46, Yangyu Chen wrote:
>>>>>> On 5 May 2025, at 16:34, Kyrylo Tkachov <ktkac...@nvidia.com> wrote:
>>>>>>
>>>>>>> On 4 May 2025, at 19:19, Yangyu Chen <c...@cyyself.name> wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> This patch series introduces support for the target_clones profile
>>>>>>> option in GCC. This option enables users to specify target_clones
>>>>>>> attributes in a separate file, allowing GCC to generate multiple
>>>>>>> versions of the function with different ISA extensions based on the
>>>>>>> specified profile. This is achieved using the -ftarget-profile
>>>>>>> option.
>>>>>>
>>>>>> Interesting idea, but the terminology is confusing as is.
>>>>>> In GCC “profile” usually refers to an execution profile gathered through
>>>>>> PGO instrumentation or perf.
>>>>>> Whereas here I think you use “profile” to mean a “RISC-V profile” which
>>>>>> is something like a set of target architecture extensions?
>>>>>> Thanks,
>>>>>> Kyrill
>>>>>>
>>>>> Sorry for the unclear information. The target profile here refers
>>>>> to the target_clones attribute for each function. You can find an
>>>>> example in the second patch.
>>>>
>>>> I was also confused by the naming initially. Maybe something like
>>>> "-ffunction-clone-table" instead?
>>> Indeed. I will change that in the next revision.
>>>>
>>>>> For instance, we want a function foo to generate default and RISC-V
>>>>> vector targets, while a function bar should generate default and
>>>>> zba,zbb targets. The corresponding source code could be as follows:
>>>>> ```
>>>>> __attribute__((target_clones("default","arch=+v")))
>>>>> void foo();
>>>>> __attribute__((target_clones("default","arch=+zba,+zbb")))
>>>>> void bar();
>>>>> ```
>>>>> But if we have a target profile, we can describe it as follows in
>>>>> a separate file:
>>>>> ```
>>>>> foo:default#arch=+v
>>>>> bar:default#arch=+zba,+zbb
>>>>> ```
>>>>
>>>> As every function needs the default version it might be nice to make that
>>>> implicit. We can then avoid representing and subsequently diagnosing
>>>> invalid files. This could then be:
>>>>
>>>> ```
>>>> foo:arch=+v
>>>> bar:arch=+zba,+zbb#+v
>>>> ```
>>> Great idea! This will make the table simpler.
>>>>
>>>> Additionally, I think ideally the file can express functions disambiguated
>>>> by file, signature, and namespace.
>>>> I imagine we could use similar syntax to gdb supports?
>>>>
>>>> For example:
>>>>
>>>> ```
>>>> foo |arch=+v
>>>> bar(int, char) |arch=+zba,+zbb
>>>> file.C:baz(char) |arch=+zba,+zbb#arch=+v
>>>> namespace::qux |arch=+v
>>>> ```
>>> Also a great idea. However, I think it's not easy to use to implement
>>> it now in GCC. But I would like to accept any further feedback if
>>> we have such a simple API in GCC to do so, or if it will be implemented
>>> by the community.
>>> And something behind this idea is that I'm researching auto-generating
>>> target clones attributes for developers. Only accepting the ASM
>>> name is enough to implement this.
>>
>> Ah that makes sense, apologies I missed that.
>>
>> I think accepting the assembler name is good, and solves the overloading
>> ambiguity issue.
>>
>> Maybe we can use the pipe '|' instead of ':' in the file format to leave
>> room for both in future?
>
>
> I will consider using the pipe '|' in the next revision. Thanks for
> the advice.
How about instead using a json file? There's already a parser built into
the compiler.
That has the advantage of being an established format that generators
can use. It would also allow other ways of specifying the functions
to be added in future.
Thanks,
Richard
