RE: 8179527: Implement intrinsic code for reverseBytes with load/store
Hi Michihiro and Gustavo,
thank you very much for implementing this change.
@Gustavo: Thanks for taking a look.
I think that the direct match rules are just there to satisfy match_rule_supported. They don't need to be fast, they are just a fall back solution.
The goal is to exploit the byte reverse load and store instructions which should match in more performance critical cases.
Now my review:
Looks good except a minor formatting request:
LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532 << 1),
LDBRX_OPCODE = (31u << OPCODE_SHIFT | 532u << 1),
to be consistent.
The comments // X-FORM should be aligned with the other ones.
I'm concerned about the additional match rules which are only used for the expand step. They could match directly leading to incorrect code. What they match is not what they do.
I suggest to implement the code directly in the ins_encode. This would make the new code significantly shorter and less error prone.
I think we don't need to optimize for Power6 anymore and newer processors shouldn't really suffer under a little less optimized instruction scheduling. Would you agree?
Displacements may be too large for "li" so I suggest to use the "indirect" memory operand and let the compiler handle it. I know that it may increase latency because the compiler will need to insert an addition which could better be matched into the memory operand of the load which is harder to implement (it is possible to match an addition in an operand).