[Chicken-hackers] [PATCH] Fix (restore?) specializations from types.db when compiling core itself

[Peter Bex]

Hi hackers,

A while ago I was digging into CHICKEN's worrisome I/O performance and I
noticed that read-char isn't compiled as efficiently as one would expect
it to be: the argument type check isn't inlined as it should, even though
there is a specialization in types.db, and it calls read-char/port which
is a full CPS call.  See also ticket #1219.

So today I took a look into why this is happening, and the reason seems
pretty simple: normally, when you have a file that contains code and
type declarations plus specializations, the type is marked as "declared"
rather than the default, which I guess is "inferred".  Types declarations
loaded via an external database should be treated identically to inline
declarations, I think, but those are currently not marked as "declared".

The missing marking causes the code in "initial-argument-types" and
"variable-result" (in scrutinizer.scm) to use the "*" wildcard rather
than the actual declared type.  This somehow means specializations won't
be triggered.  I'm not 100% sure why that's the case.

There was another ticket made by Felix, #745, which indicates that
really we want a user definition to invalidate type specialization for
a procedure of the same name.  This was closed after I noted that
specializations already don't occur.  However, the current behaviour is
more of an accident than an actual feature: the specializations list on
the identifier isn't removed, and in fact, if the procedure's type is
declared inside the file, this will cause the specializations to be
triggered again, even if the type is different (I think).

So I re-opened #745 as this will need a "proper" fix, obliterating the
specializations and declared procedure type.

The first attached patch simply adds the "declared-type" variable mark
to all types that were loaded via an external database.  Adding this
also found some inconsistent types between types.db and the definitions
in library.scm and tcp.scm, so I've fixed those as well (the third patch).

The second patch simply copies the body of read-char/port into read-char,
exactly like we already do in write-char and write-char/port.  I'm not
sure that's the best solution, but it's better than the current situation.

Attached is also a diff of the benchmarks, and you can clearly see the
benefit this has in the difference between "test" and "master" on the
kernwyk-wc and kernwyk-cat benchmarks, as I hoped it would.  The slatex
benchmark doesn't show much of an improvement, but it does a lot more
than just reading, of course.  I can't really explain the differences in
the other benchmarks, but I guess some of those are just noise, or the
result of changing stacks due to the specializations in library.scm.

Cheers,
Peter

0001-Mark-external-type-declarations-as-declared.chicken-5.patch
Description: Text Data

0002-Avoid-CPS-call-in-read-char-to-read-char-port.chicken-5.patch
Description: Text Data

0003-Fix-a-few-incorrect-type-declarations.chicken-5.patch
Description: Text Data

0001-Mark-external-type-declarations-as-declared.master.patch
Description: Text Data

0002-Avoid-CPS-call-in-read-char-to-read-char-port.master.patch
Description: Text Data

0003-Fix-a-few-incorrect-type-declarations.master.patch
Description: Text Data

benchmarks.diff
Description: Text Data

signature.asc
Description: Digital signature