On Mon, Oct 14, 2024 at 1:40 PM Yangyu Chen <chenyan...@isrc.iscas.ac.cn> wrote: > > > > > On Oct 14, 2024, at 12:32, Kito Cheng <kito.ch...@gmail.com> wrote: > > > > I prefer not to handle the extension implication rules, as it's easy > > for them to get out of sync, and this should be the linux kernel's > > responsibility rather than libgcc's. > > > > I still prefer to handle the extension here since users may use old > versions / LTS versions of the Linux kernel, which have no some > implied extensions. > > I have another patch to let GCC set the minimal required bits to > provide the best compatibility. However, in some cases, such as > some targets requiring Zve32x but not full V and users who have > kernel version < v6.11, the resolver will not probe the Zve32x > extension. Thus, we will not use the corresponding version. If we > check V in zve32x ifunc resolver, building it in gimple will make > it harder to maintain. Thus, I think both handling minimal extension > in libgcc and having the minimal feature bits to generate the IFUNC > resolver will be a better way to handle this. > > Meanwhile, handling it in this way does not increase the maintenance > overhead since we don’t need to handle the extensions and implied > extensions appear in the same version of the Linux kernel. So implied > extensions like Zbc->Zbkc does not need to be handled here. Till now, > we only need the handle C->Zca, Zcd, Zcf and V->Zve32x, Zve32f, > Zve64x, Zve64f, Zve64d.
I am OK with minimal extension implication rules, like what you implement now, but I am still concerned about implementing full rules.
