Hi all, I would like to discuss the intended meaning of ARGDIR_IN/OUT in core.ops (core_ops.c).
s. also #16838 and #16895 imcc uses the IN/OUT information for determining the life status of a symbol, which is the base for register allocation, so it's crucial. The meaning in imcc is like: IN ... register is read, (or exists) OUT ... register is written to, i.e. starts a new life cycle when we have a op sequence: 1 set I0, 5 # I0 is alive 2 set I1, I0 # here too, gets read 3 set $I55, $I56 # no use of I0 here N-1 ... # but some temps need a register N set I0, 6 # I0 starts a new life here then - I0 is alive at [1,2] and at [N,..] because it's not read again after 2 and in N, it start's a new life cylce. So the register allocator may use the register I0 between 3 and N-1 for allocation of other temporary variables, which need a register. So similar example with PMCs 1 new P0, .PerlUndef # start life of P0 2 set P0, 5 # call P0's vtable->set_integer_native(5)... 3 ... # no set P0, Py here N-1 ... # no new P0, xx here N set P0, 6 # call same's PO set_integer_native(6) so P0 is alive in the whole instruction sequence [1,N], and may not be used in between. This should be - from my (imcc) POV - reflected by these IN/OUT settings: op set(in PMC, in INT) op set(in PMC, in STR) op set(in PMC, in NUM) op set(out PMC, in PMC) # ok, $1 points to $2 now # P[i] = x op set(in PMC, in intkey, in x) # P[KEY] = x op set(in PMC, in KEY, in x) # p[KEY] = P[KEY] op set(in PMC, in KEY, in PMC, in KEY) Actually current imcc overrides core.ops with these opterations and changes them to "in", and does fail, when core.ops is regarded for these operations and "out" is used. The only other usage of this ARGDIR info is in JIT, where I really, don't know, how (if even for PMCs) it's used there. Comments welcome, TIA leo
