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

[Jovan Dmitrovic]

Hello Adhemerval,

sorry for answering this late, your mail fell into the cracks of my inbox,
and only when I was reviewing upcoming v4 of this patch set have I 
noticed it.

I would like to point out that unaligned instructions are not mentioned
explicitly, so technically the compiler has the choice of choosing what is
the best in this situation (we use a little coaxing here, but nothing
too egregious). I imagine that unaligned hardware instructions should be 
faster than
alignment adjusted equivalents.

I believe ran the benchmark with and without this patch and
had improvements, so it has merit to be applied regardless.

Thanks and sorry for the delay,
Jovan

On 18. 9. 25. 15:25, Adhemerval Zanella Netto wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> 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