IMCC optimizer instruction duplication and opcode write/reads
Amos Robinson
an instruction is
INS(interp, unit, ins->op, "", ins->r, ins->n_r, ins->keys, 0);
However, this doesn't seem to work with e.g. set_args.
Is there some easy way to duplicate an instruction, or should I just give
up when I see a pcc directive?
Also, with regards to in/out/inout of opcodes:
pop is currently described as (out ?, in PMC)
However, with say used_once optimizations, you want to know which registers
are written to, and read from.
I looked and thought that pop should be (out ?, inout PMC) because it
changes the array/whatever.
Amos Robinson
Leopold Toetsch
On Dec 31, 2005, at 15:43, Amos Robinson wrote:
> I was wondering if anybody could help: the best I've found for
> duplicating
> an instruction is
> INS(interp, unit, ins->op, "", ins->r, ins->n_r, ins->keys, 0);
A copy_ins() function would be nice, if needed.
> However, this doesn't seem to work with e.g. set_args.
Why?
> Is there some easy way to duplicate an instruction, or should I just
> give
> up when I see a pcc directive?
Duplicating e.g. a function call needs a bit more effort, e.g.
allocation and filling the pcc_sub structure.
> Also, with regards to in/out/inout of opcodes:
> pop is currently described as (out ?, in PMC)
> However, with say used_once optimizations, you want to know which
> registers
> are written to, and read from.
> I looked and thought that pop should be (out ?, inout PMC) because it
> changes the array/whatever.
The in/out doesn't tell you if a PMC is modified like in 'pop' but
tells you if the register is unmodified (in) or has a new contents
after the operation (out). E.g.
pop P0, P1 # (out, in)
doesn't modify P1 (it is a pointer to the same location before and
after the operation - if the contents of the array changes, doesn't
matter at all). But P0 has a total new value after the operation,
namely a pointer to the previously last value of P1.
This information is needed for register allocation inside imcc itself
and in the JIT. The 'out' means that the life range of the old 'P0'
ends at that instruction and a new life range of 'P0' is starting.
> Amos Robinson
leo
Amos Robinson
but not send them (not even to itself!)
>
> On Dec 31, 2005, at 15:43, Amos Robinson wrote:
>
--
>
> A copy_ins() function would be nice, if needed.
>
>> However, this doesn't seem to work with e.g. set_args.
>
> Why?
In my local repo with branch_cond_loop optimizations,
parrot -v -dFFFF runtime/parrot/library/Data/Dumper/Default.pir
gives me...
-- SNIP --
push %s, %s push
push %s, %s push
sprintf %s, %s, %s sprintf
set %s, %s[%s] set
error:imcc:The opcode '_' (<1>) was not found. Check the type and number
of the
arguments
in file 'runtime/parrot/library/Data/Dumper/Default.pir' line 342
The op after the set is a method call: self."dump"(...). If I change it to
say, a label (that is being used), it works fine.
I can get it working for now by checking that it's not gonna move any PCC
directives - at the moment it just doesn't like any sort of branches.
>
--
>
> Duplicating e.g. a function call needs a bit more effort, e.g.
> allocation and filling the pcc_sub structure.
>
Hmm, okay. I was hoping I could've just copied the set_args, get_results,
and callmethodccs. I'll have a look further into the PCC stuff you did.
--
>
> The in/out doesn't tell you if a PMC is modified like in 'pop' but tells
you if the register is unmodified (in) or has a new contents after the
operation (out). E.g.
>
> pop P0, P1 # (out, in)
>
> doesn't modify P1 (it is a pointer to the same location before and after
the operation - if the contents of the array changes, doesn't matter at
all). But P0 has a total new value after the operation, namely a pointer
to the previously last value of P1.
>
> This information is needed for register allocation inside imcc itself
and in the JIT. The 'out' means that the life range of the old 'P0' ends
at that instruction and a new life range of 'P0' is starting.
>
Ahh, okay. How many ops would you say there are that change contents of
non-LHS args? I don't want to cause too much trouble, but for used_once I
think some way of checking whether it's one of those is necessary, even if
I just hard-code the checks.
>> Amos Robinson
>
> leo
Leopold Toetsch
On Jan 2, 2006, at 16:53, Amos Robinson wrote:
> error:imcc:The opcode '_' (<1>) was not found. Check the type and
> number
> of the
> arguments
Looks strange. gdb might help.
> Hmm, okay. I was hoping I could've just copied the set_args,
> get_results,
> and callmethodccs. I'll have a look further into the PCC stuff you did.
Copying these instructions should work after all the directives are
expanded, i.e. when the optimizer sees it.
> Ahh, okay. How many ops would you say there are that change contents of
> non-LHS args? I don't want to cause too much trouble, but for
> used_once I
> think some way of checking whether it's one of those is necessary,
> even if
> I just hard-code the checks.
Just some 'gcd' opcodes with multiple out args come to my mind
currently - but please recheck.
leo