Missaligned memory accesses from JDK

[Vladimir Kempik]

Hello Andrew
Your idea looks good, but a question arises:

If I change emit_int16() to use Bytes::put_native_u2() then few platform might see perf penalty, 
I found these platforms to do aligned store in put_native_u2() unconditionally:
ppc and arm32 doing same thing:
static inline void put_native_u2(address p, u2 x) {
    if ((intptr_t(p) & 1) == 0) {
      *(u2*)p = x;
    } else {
      p[0] = x;
      p[1] = x >> 8;
    }
  }

and x86 doing  this ():

 static inline void put_native_u2(address p, u2 x)   { put_native<u2>((void*)p, x); }

  template <typename T>
  static inline void put_native(void* p, T x) {
    assert(p != NULL, "null pointer");

    if (is_aligned(p, sizeof(T))) {
      *(T*)p = x;
    } else {
      memcpy(p, &x, sizeof(T));
    }
  }

Should I then make ppc/arm32/x86 to do aligned stores in put_native_u2 only if AvoidUnalignedAccesses is true ?

Thanks in advance, Vladimir.
> 27 марта 2023 г., в 12:55, Andrew Haley <aph-open at littlepinkcloud.com> написал(а):
> 
> On 3/20/23 15:26, Vladimir Kempik wrote:
>> Could you please suggest on best way to make emit_intX methods not perform misaligned memory stores ?
> 
> You should change emit_int16() to use Bytes::put_native_u2(). You should change
> RiscV's put_native_u2() to do whatever the back end needs, respecting
> AvoidUnalignedAccesses.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/riscv-port-dev/attachments/20230327/f59f40ad/attachment.htm>