Missaligned memory accesses from JDK

[Maurizio Cimadamore]

Most likely, this is the wrong compiler-dev - I suggest you forward this 
here:

https://mail.openjdk.org/mailman/listinfo/hotspot-compiler-dev

Cheers
Maurizio

On 20/03/2023 17:10, Vladimir Kempik wrote:
> Adding compiler list.
>
> Could you please suggest on best way to make emit_intX methods not perform misaligned memory stores ?
> Talking about src/hotspot/share/asm/codeBuffer.hpp fromhttps://github.com/VladimirKempik/jdk/commit/18d7f399ce1bc213b2495411193938d914d3f616#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae
>
> Regards, Vladimir
>
>> 20 марта 2023 г., в 12:42, Vladimir Kempik 
>> <vladimir.kempik at gmail.com> написал(а):
>>
>>
>>>  For each emit_intX functions modified, I see there is a 
>>> correspondent version which handles unaligned access. For example, 
>>> 'void emit_int16(uint8_t x1, uint8_t x2)' for 'void 
>>> emit_int16(uint16_t x)'
>>>  So if we encounter an unaligned access issue when using 
>>> 'emit_int16(uint16_t x)', shouldn't we change the callsite to use 
>>> 'emit_int16(uint8_t x1, uint8_t x2)' instead?
>>
>> Hello
>> not exactly
>> 'void emit_int16(uint8_t x1, uint8_t x2)
>> will always use slow version ( store byte)
>>
>> but
>> void emit_int16(uint16_t x)
>> will use slow version only on unaligned stores. if store is aligned, 
>> it will use "store half", which should be faster.
>>
>> So we can’t always use emit_int16(uint8_t x1, uint8_t x2) at callsite.
>>
>> and we can’t decide which one to use at callsite as callsite should 
>> be unaware of end() value inside CodeSection class
>>
>> Regards, Vladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230320/5a346ceb/attachment.htm>