On the 0x2EA day of Apache Harmony Estelle Liu wrote: > Hi,all, > I noticed that the *aload* or *astore *in bytecode are not always > translated into *Op_LdVar *or *Op_StVar* in HIR.
LdVar and StVar are generated when several stores (non-consequent, in different basic blocks) are met on a load point. In case of simple 1:1 store-and-load translator tries to "prematurely optimize" :) and put a temporary variable in place (avoiding hypothetical memory store/load), which is a straightforward intention, but can be done more naturally within other very simple and fast optimizations (simplifier?). some other cases of LdVar/StVar generation exist, for example in translation of "jsr" and "ret" instructions, but I cannot enlist them all now. > But in which cases,for what kind of variables in bytecode, the > translations into *Op_LdVar *or *Op_StVar* would happen? Is it something to > do with Class VariableIncarnation in file "JavaLabelPrepass.h" ? yes, there is some corellation between Op_LdVar, Op_StVar and VariableIncarnation :) You know, each method's java bytecode has an array of "local variables" where operations can store and load pieces of data by a statically defined index. If variables from different basic blocks are stored into one "slot" of local variable's array, they should be associated to this slot as "incarnations". And if it happens that the slot is "used" further, the incarnations should be "merged" into one variable, and a single common type should be precomputed for the slot. Estelle, what kind of things do you want to do with these opcodes? Alternatively, you can probably think of an extra "CFG transformation pass" to do you job. JavaLabelPrepass is really crappy, I would not suggest anyone to modify it except a complete rewrite of the whole translator. The latter should be awesome :) -- Egor Pasko
