[code-reflection] RFR: Implement shift ops

[Hannes Greule]

On Thu, 11 Apr 2024 22:07:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The naming seems fine for these operations, and the compiler mnemonics are a little less clear IMO that those for comparisons. If you want to use something more mnemonic-like i suggest you use the same names we use for operators in the Vector API (see `jdk.incubator.vector.VectorOperators`), in fact i lean towards than naming.

I don't have a strong opinion on the naming. I can change it to the one from the Vector API if you want.

> Hmm... interesting. When `byte` is on the rhs I presume it will be widened to `int`, and there will be a conversion operation inserted into the code model?

Yes, that's at least what I intended in the current implementation

> I am uncomfortable with these binary operations have different operand integral types in some cases (long << int, or int << long). It may be better to more uniform for the compiler generated code models and insert conversion operations (which i believe should not change program meaning, and we can optimize for bytecode generation).

Semantics are kept as only the lower 5/6 bits of the rhs are relevant for the shift. Alternatively, the rhs could always be `int`, that would be equal to the bytecode instructions. With both sides having equal types, we only need to be careful with the handling of `boolean` then (e.g. #48 adds `BooleanType` to some binary instructions, and I guess it works and makes sense on bytecode level for those instructions).

> Follow on PR?

Okay, let's do that later.

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

PR Comment: https://git.openjdk.org/babylon/pull/49#issuecomment-2056234021