[m-rev.] for review: start using type_spec_constrained_preds pragmas

[Zoltan Somogyi]

On 2024-02-09 17:57 +11:00 AEDT, "Julien Fischer" <jfischer at opturion.com> wrote:
>> My laptop's timings are too variable to be able to measure
>> the speed impact of this diff. For tools/speedtest, I got a 0.7%
>> speedup; for tools/bootcheck -j6, approx the same slowdown.
>> If someone with a less volatile machine could try it out,
>> I would be grateful.
> 
> I will do so. I did try an earlier version of this change out on my JSON
> library and got a very small speedup. I have some theories about why
> this is, but need to have closer look at what the compiler is doing.

Thank you.

My guess is that

- the fraction of the time that the compiler spends in the specialized code
  is small (in fact, it should be zero on invocations that don't write to
  .int* or .*opt files, or generate error messages), and

- the speedup of that fraction is probably itself at the few-percent-at-most
  level.

That's why I don't think tools/speedtest is a particularly good test.
Doing timings of building .intN and/or .*opt files would be better.

> Question: is there a definitive list of what's allowed to appear inside
> .opt files somewhere? The list given in the comment at the top of
> compiler/intermod.m is incomplete: it doesn't mention typeclasses or
> instances for example.

Fergus and Simon did not leave any such documentation. I added
it for .intN files to notes/interface_files.html, though it is not complete.

For .*opt files, the best info is the definitions of the parse_tree_plain_opt
and parse_tree_trans_opt types in prog_item.m. I derived those from the
code in intermod.m, and every kind of item in them *is* actually something
that the compiler can put into .*opt files.

With interface files, there are a good number of constraints on their
contents that you cannot express in types, partially (but not always)
because the constraint applies to the relationship between two or more items,
rather than being just on the form of a single item. There are probably
such constraints on the contents of .opt files, but (a) I don't know what
they are, though (b) I am pretty sure that there are many fewer such
constraints on .opt files than on .intN files. (.trans_opt files are so simple
that I don't think they have such constraints.)

The module comment of intermod.m should be modified to point
to prog_item.m. Do you want to do it, or should I?

Zoltan.