[code-reflection] RFR: Implement shift ops

[Paul Sandoz]

On Mon, 15 Apr 2024 08:44:25 GMT, Hannes Greule <hgreule 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.
>

Ok, lets go with the Vector API names for now.

 
> > 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. 

Yes. I am just thinking about consumers of the model. It's easier to reason about if more uniform, and we should be careful not to bias towards bytecode generation.


> 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).

We should ask @asotona about that. In the Java language boolean values cannot participate in numeric expressions, since a boolean type is not a numeric type. If they appear in a code model (e.g. perhaps an invalid one) it seems reasonable to fail when translating to bytecode.

For now lets go with what you have. Recommend you add a comment, and we can potentially revisit later on.

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

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