Re: [PATCH] riscv: avoid vle8ff in vector strcmp loop

On 6/15/26 21:54, Florian Weimer wrote:
>> Limit vl by the minimum distance from the input pointers to the next 4K
>> boundary, and use normal vle8.v loads in the main loop.  This keeps the
>> loads page-safe while avoiding the vl update dependency from vle8ff.v.
> 
> Doesn't this make the implementation incompatible with the Zimt (memory
> tagging) extension?  Or isn't this a problem today?
> 

Thanks for raising this concern.

The "Memory Tagging Ratification Plan" describes that the software
ecosystem impact is expected to be handled through loader/glibc support.
In particular, the "Software Ecosystem Impacts" section states:

"It is expected that any object compiled with memory tagging option must
have a marker flag which can be recognized by loader or glibc. Thus user
space can implement policy (if it wants) to enable tagging if all objects
in address space are tagging aware."

Therefore, I think the decision of whether these RVV optimized string
implementations can be used in the presence of memory tagging should be
part of glibc's selection policy, for example through the ifunc resolver
or another future dispatch mechanism.

The implementation itself only guarantees the behavior required by the
current ABI and does not make a policy decision about memory tagging.
If Zimt requires avoiding such accesses or selecting a different
implementation, the dispatch layer should be able to select an
implementation accordingly.

This concern may apply not only to strcmp, but also to other optimized
string/memory routines which may use fault-only-first loads (such as
strlen, memchr, or similar routines). Therefore, I think the integration
point should be the common glibc dispatch mechanism rather than each
individual optimized implementation.

As Zimt support is not yet integrated into glibc, I think this can be
addressed together with the future memory tagging ABI support.

-- 
Chengrong Dai