hg: valhalla/valhalla/langtools: Add support for tracking 'any'-related opcodes

[Maurizio Cimadamore]

This looks promising - are you envisioning some kind of 'inference' in 
the VM in order to figure out the 'width' of the v* opcodes? That might 
be non-trivial as it would probably mean propagate type info from the 
local var table attribute? An alternative perhaps could be to accept an 
extra operand containing the 'width'  (i.e. 1 for int, 2 for 
double/long, n for value types).

Maurizio

On 28/07/14 16:26, John Rose wrote:
> On Jul 28, 2014, at 4:09 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> yes, if you do local var slot renaming for value type when parsing the bytecode,
>> you can use the same mechanism for double.
> Here is a concrete suggestion, to get rid of double slots completely in the setting of value types:
>
> Deprecate and remove [ld][a]?load* and [ld][a]?store* opcodes.
>
> In generated bytecodes, replace them by the corresponding v* opcodes (which would apply to long and double primitive values, as well as non-primitive, non-reference values).
>
> A few other opcodes (d2i, etc.) are kept as-is, but the slot-pair semantics are removed for them also.
>
> Later, repurpose those opcode points for other things.  (This will free the d* or l* series of instructions for later use.)
>
> For compatibility, old class file versions would continue to use slot-pairs (and will not recognize v* bytecodes).
> New class file versions would refuse (at least some of) the [dl]* bytecodes.
>
> — John