RFR: 8276314: [JVMCI] check alignment of call displacement during code installation

[Tom Rodriguez]

On Wed, 3 Nov 2021 16:00:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> I agree.  I think C2 has always aligned and C1 used to check is_MP but no longer does.  Requiring JVMCI compilers to always align seems right, particularly since we don't expose is `is_MP` through JVMCI.  Graal and C1 actually appear to over align the displacement by aligning it to BytesPerWord while C2 always aligns to 4 which is all that is required.  It's odd that alignment check in NativeCall isn't simply `displacement_offset() % 4`.  The existing check implies that it's ok to use a misaligned offset as long as it starts and ends within an 8 byte region but I don't know that that would really work and none of the compilers actually take advantage of it.  That's probably beyond the scope of this PR.  Actually `verify_alignment` checks that it's aligned on BytesPerInt so maybe `is_displacement_aligned` should unify around that definition.
>
> I will remove the `is_MP()` calls.
> 
>>while C2 always aligns to 4
> 
> I'm having trouble finding where that is done - can you please point it out.

It's deeply hidden.  in x86_64.ad, it specifies the call alignment as [4](https://github.com/tkrodriguez/jdk/blob/master/src/hotspot/cpu/x86/x86_64.ad#L13028) and in [compute_padding](https://github.com/tkrodriguez/jdk/blob/master/src/hotspot/cpu/x86/x86_64.ad#L493) it uses that alignment value to align the offset of the displacement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6218