> On Oct 14, 2024, at 15:15, Kito Cheng <kito.ch...@sifive.com> wrote:
>
>>> I am OK with minimal extension implication rules, like what you implement
>>> now,
>>> but I am still concerned about implementing full rules.
>>
>> I didn't know the reason for the concerns. Maybe I didn't tell it
>> clearly.
>
> Current implementation didn't implement full implication rule according spec,
>
> e.g.
> zve32f -> f
> zve32d -> zve32f, d
> zve64x -> zve32x
> ...
> zfh -> f
> ...
>
> however I know it's not meaningful because the kernel handled part of that.
>
Yes. We only need to care about the new implied extensions provided
by newer versions of kernel hwprobe.
Since F was introduced in Linux v6.4 hwprobe, we don't need to set
F for Linux v6.11 introduced Zve32f.
That's why I wrote, "Every time we add new extensions, we should
check if **PREVIOUS** extensions imply the new extension and set
the corresponding bit.” comment in the file.
>>
>> I want both sets of implied extensions in libgcc here and also to
>> use a minimal feature bit for the IFUNC resolver to solve. I think
>> this is the safest way to provide compatibility for both older
>> versions of Linux kernels and users who only set a minimal extension
>> (like Zve32x but no V).
>
> So yes, I know your point here, but I just not prefer to implement all
> implication rule here...:P
>
>>
>> Would this be acceptable? If OK, I will fix the C->Zcd for RV64 only
>> and submit the next revision.
>
> Yes, fixing that and without introducing more implication rules is OK to me.
>
>>
>> Thanks,
>> Yangyu Chen
>>
