[PATCH v3 4/6] mips: Add C implementation of memcpy/memset

[Adhemerval Zanella Netto]

On 18/09/25 10:19, Jovan Dmitrovic wrote:
> Hello Adhemerval,
> 
>> And TARGET_STRICT_ALIGN is set for -mstrict-align, which in turns defines
>> the __mips_strict_alignment.
>>
>> Wouldn't be simpler to use
>>
>> #if !defined __mips_strict_alignment && mips_isa_rev >= 6
>> # define UNALIGNED_INSTR_SUPPORT 1
>> #else
>> # define UNALIGNED_INSTR_SUPPORT 0
>> #endif
> 
> I see, this is a neater way to write this, I wasn't aware of 
> __mips_strict_alignment.
> I will refactor this and other macros for sake of brevity.
> 
>> Also, for UNALIGNED_INSTR_SUPPORT what does mean performance-wise when
>> load/store instruction are used on unaligned memory? Just a performance
>> hit from the hardware or would it be emulated by the kernel (as for some
>> ARM chips)?
> 
> This is what the MIPSR6 ISA manual says:
> 
>> Pre-Release 6: The effective address must be naturally-aligned. If 
>> either of the 2 least-significant bits of the address is
>> non-zero, an Address Error exception occurs.
>> Release 6 allows hardware to provide address misalignment support in 
>> lieu of requiring natural alignment.
> 
> In short, misaligned load/store instructions such as LW or SW throw an 
> exception pre-R6, and R6 has misalignment support. Handling of 
> misalignment is implementation dependent. Pre-R6 there are special 
> load/store instructions such as LWL and SWL that allow for misaligned 
> loading and storing. Those instructions were removed in release 6 as 
> they are unnecessary.

But for pre-R6 is really worth to use LWL/SWL on unaligned memory in
comparison on adjusting the algorithm to user only aligned accesses?
I trying to understand if it worth to have two different implementation
for unaligned_words.

> 
>> The ENABLE_PREFETCH_CHECK is racy and only meant to debug outsize glibc on in
>> very specific cases.  I think it would be better to just remove it.
> 
> Seems reasonable to me.
> 
> Thank you for your time,
> Jovan