[RfC] disable unused vtable entries

[Leopold Toetsch]

When looking at classes/*.c struct _vtable temp_base_vtable {} by far
the most vtable methods are unused or uncovered by opcodes:
- *bignum*
- {shift,unshift,push,pop}_keyed*
- {math,logical,boolean,string}_keyed*
- _same*
These methods all delegate either directly or indirectly through their
parent(s) to default.

IMHO we should disable all unused and uncovered methods by either
stripping down vtable.tbl or marking active methods in this file and
only process these.

This would make changes in the class hierarchy/vtable layout/... much
simpler and the class files more informative. When a method actually
gets a real implementaion it could be readded easily.

Comments welcome
leo

[Leopold Toetsch]

In perl.perl6.internals, I wrote:
> When looking at classes/*.c struct _vtable temp_base_vtable {} by far
> the most vtable methods are unused or uncovered by opcodes:

Some more details (vtbc.pl is below):
$ ./vtbc.pl |grep same | wc -l
20
$ ./vtbc.pl |grep bignum | wc -l
25
$ ./vtbc.pl |grep keyed | wc -l
123

$ ./vtbc.pl |grep -v keyed | grep -v same | grep -v bignum
vtable coverage
vtable.tbl has 265 entries
core_ops.c has 94 entries + 5 internally used
set_number
substr
cmp_num
bitwise_shl_int
bitwise_shr_int
set_integer
set_string
concatenate_native
cmp_string
invoke_pmc
modulus_float
substr_str
repeat_int
subtype
get_pmc
166 unused

- _same are intended as short cuts, when all data types are known. But
IMHO to know what data types are involved, you have to test the PMC
types - this is what the normal methods do anyway, so these methods
are probably superfluous.
- _keyed - by far the most group and IMHO will never be implemented due
to the huge opcode count necessary to implement them.
- _bignum will be needed
- from above list: set_integer, set_number, set_string always use their
_native variants so they are probably unneeded.
Others might be missing or unneeded - who knows.

#!/usr/bin/perl
#
#vtable coverage vtbc.pl

use FindBin;
use lib 'lib';
use lib "$FindBin::Bin/..";
use lib "$FindBin::Bin/../lib";
use Parrot::Vtable;
use strict;

my $default = parse_vtable("./vtable.tbl");
printf " vtable coverage\n";
printf " vtable.tbl has " . scalar (@{$default}). " entries\n";

my %methods;
foreach my $method (@{$default}) {
$methods{$method->[1]}=1;
}

my %vops;
open IN, "core_ops.c" or die("can't read core_ops.c\n");
while (<IN>) {
$vops{$1}++ while (/VTABLE_(\w+)/g);
}
close(IN);
my @int = qw/morph mark destroy elements init_pmc/;
printf " core_ops.c has ". keys(%vops) . " entries + " . scalar(@int) .
" internally used\n";

foreach my $i (@int) {
$vops{$i}++;
}

my $unused;
foreach my $c (keys(%methods)) {
$unused++, printf "$c\n" unless $vops{$c};
}
printf " $unused unused\n";

Comments still welome
leo

[Nicholas Clark]

> Comments still welome

No-one commented, did they? Did anything come of this?

Nicholas Clark

[Dan Sugalski]

Got Warnocked, I think. I'm partway through partitioning the vtable
up to make overriding vtables on a per-PMC basis less expensive. I'm
pretty sure that most of the keyed variants will end up being used,
but we may end up pruning a bunch of these out.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Leopold Toetsch]

Dan Sugalski wrote:

> Got Warnocked, I think. I'm partway through partitioning the vtable up
> to make overriding vtables on a per-PMC basis less expensive. I'm pretty
> sure that most of the keyed variants will end up being used, but we may
> end up pruning a bunch of these out.

The _keyed math, logical and binary ops are history. As mentioned
several times, I don't see any chance to implement them without having
about 64 times the opcount we have now.
This doesn't mean, that we never support multi keyed ops:
$ cat 3key.imc
new P0, .PerlArray
new P1, .PerlArray
new P2, .PerlArray
set I0, 0
set I1, 100000
loop:
set P1[I0], I0
set P2[I0], I0
add P0[I0], P1[I0], P2[I0]
inc I0
lt I0, I1, loop
...
$ parrot -o- 3key.imc
new P0, 22
new P1, 22
new P2, 22
set I0, 0
set I1, 100000
loop:
set P1[I0], I0
set P2[I0], I0
set P18, P1[I0]
set P17, P2[I0]
new P16, 27 # .PerlUndef
add P16, P18, P17
set P0[I0], P16
inc I0
lt I0, I1, loop
...

This code can for sure be improved, also the semantics of the LHS (new,
assign) has to be defined, but that problem has the original code too.

WRT _same opcodes: I finally found a usage for some of these, when
fixing the assign Px, Px vtables ;-) But I still can't imagine any usage
besides the set_<type>_same variants.
leo