hg: valhalla/valhalla/langtools: Add support for tracking 'any'-related opcodes
david.r.chase at oracle.com
Tue Jul 29 08:06:20 UTC 2014
On Jul 28, 2014, at 8:20 PM, John Rose <john.r.rose at oracle.com> wrote:
> On Jul 28, 2014, at 4:40 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> 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).
> Which opcode would have an ambiguous input? Can't you always tell whether it is I, J, or some specific value type?
> ...Or any other type: Seems to me that, for correctness, we only need v* and none of the [ailfd]*, if we do very simple forward-only inference, like that supported by FrameMaps already.
Do you have any plans to get rid of the invokevirtual/invokeinterface distinction?
Is it ever the case that both are legal but yield different results?
I recall that the Fortress specializer had its own stupid little special case
for dealing with this for different flavors of T’s replacement.
More information about the valhalla-dev