> On 15 May 2025, at 14:01, Alice Carlotti <alice.carlo...@arm.com> wrote:
>
> On Thu, May 08, 2025 at 09:41:08PM +0800, Yangyu Chen wrote:
>>
>>
>>> On 8 May 2025, at 18:36, Richard Sandiford <richard.sandif...@arm.com>
>>> wrote:
>>>
>>> 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:
>>>>>>>
>>>>>>> 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 for this useful information. I also want to extend the current
>> function multi-versioning to have the ability to set -mtune for
>> different micro-architectures in the future. Using JSON can provide
>> more extensibility in the future.
>>
>> Thanks,
>> Yangyu Chen
>
> For AArch64, we already support setting different tuning options for different
> versions (this is why I deliberately allowed the "target" attribute to be used
> on a function that also has the "target_clones" or "target_version"
> attribute).
>
>
> What we don't support is allowing different microarchitectures to affect the
> version selection algorithm when the architecture features remain the same.
> This sounds like a nice idea, but on further consideration I think there are
> several reasons why we shouldn't try adding this. I think these reasons apply
> at least to the AArch64 and RiscV ecosystems.
>
> - Detecting specific microarchitecture properties (e.g. details like cache
> size, pipeline widths, instruction latencies) would be somewhere between
> difficult and impossible. It certainly isn't something that can be packaged
> into a standard user-friendly attribute.
>
> - Detecting specific microarchitectures by individual names would probably
> require writing long lists of known microarchitectures, and wouldn't be able
> to make a non-default choice for microarchitectures that weren't known about
> when the software was written.
>
> - The only good way I can see to systematically group microarchitectures that
> works for unknown future microarchitectures is to look at what architecture
> version or features they support. But then we're back to using architecture
> versions as the basis for version selection, which we already support.
>
Indeed, it's not common to have such a wide range of versioning
options. However, if it's possible to implement in the future and
we use the same type of target string to express the tune option
along with the ISA extension, it won't affect the current design.
I'm currently traveling for the RISC-V summit Europe. I'll revise
this patch upon my return to work.
> I'm not saying that users should never use microarchitecture detection to
> select between different implementations of a function. I just think that
> it's
> a relatively uncommon to need to this, and that doing it well is much more
> complicated than checking whether architecture features are supported. It
> would be best to just let users write their own custom resolvers and use
> ifuncs
> (or other platform specific mechanisms) directly.
>
Indeed.
Thanks,
Yangyu Chen
