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