Opcode, LabelResolver & NewMultiArrayInstruction

[Adam Sotona]

Opcode::primaryTypeKind() forwards to LoadInstruction, StoreInstruction, ReturnInstruction, ArrayLoadInstruction, ArrayStoreInstruction, ConvertInstruction and OperatorInstruction.
Specifically, for ConvertInstruction and OperatorInstruction I haven’t found any use of the instruction type kind across ClassfileAPI and tests.
The information is only informative for these two kinds of opcodes, however it may still be usefull.
I would suggest to fix it.

Adam

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of Brian Goetz <brian.goetz at oracle.com>
Date: Tuesday, 19 July 2022 20:38
To: Michael van Acken <michael.van.acken at gmail.com>
Cc: classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Subject: Re: Opcode, LabelResolver & NewMultiArrayInstruction
> In Opcode.java, the TypeKind of ISHR & LSHR does not match the opcode:
>
>     ISHR(Classfile.ISHR, 1, CodeElement.Kind.OPERATOR, TypeKind.FloatType),
>     LSHR(Classfile.LSHR, 1, CodeElement.Kind.OPERATOR, TypeKind.DoubleType),

Whoops :)

I’m not sure how much depends on these ancillary properties of Opcode, so this may not trigger any bad behavior, but obviously this is some sort of cut and paste error.  In an earlier iteration there were tons of ancillary properties and over time they migrated elsewhere (or were not needed.).  Before we fix this, we should look at how widely the “primary type kind” property is used, and whether this is the right place for it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220720/b9289c12/attachment-0001.htm>