VM code refactor - thoughts?

Great @dmchurch! All compiled and tests nicely. Walked through most of the changes. 99% is fairly mechanical so I guess we should not expect many regression issues. As is, this is a cleanup of some of the VM interactions. It is also pretty complicated C preprocessor code which I hope we can mostly get rid of if it turns out there is a way to switch completely to the function based version. That would be a big step forward.

There is a bit weird thing going on wrt PGO optimization. First I fixed the mistake that PGO compilation didn’t work at all (Ann: SWI-Prolog 8.3.24 - #2 by jan). Using the PGO training set I now observe the following:

Version Average on bench/run.pl
Public master, normal build 0.302
Public master, PGO 0.210
VMI-Functions, normal build (functions not enabled) 0.283
VMI-Functions, PGO (functions not enabled) 0.264
VMI-Functions, normal build (functions enabled) 0.305
VMI-Functions, PGO (functions enabled) 0.270
VMI-Functions, normal build (functions enabled, registers) 0.300
VMI-Functions, PGO (functions enabled, registers) 0.252

Note that there is some variance in this. Typically running the same benchmark a couple of times has a variance of about 0.010 (about 3%). All measurements are on AMD3950X CPU, GCC 9.3.0 (Ubuntu 20.04).

The good news seems that the function version does a good job compared to the switch version. It is also nice that the new source outperforms the old one without using PGO, but it is sad that it looses over 20% compared to the old PGO version :frowning: Do you have a clue why, @dmchurch?