WIP: Add jit_compile/1, very basic JIT2

[aarroyoc]

I open this PR as I think it's good to have some code merged to not diverge a lot from the master branch.

All the JIT code is under the jit feature which is not enabled by default, so you shouldn't expect any change if you don't enable it (apart from an extra predicate, jit_compile/1, that does nothing).

There are two JITs right now: Only one is in this PR

• JIT1 was my first attempt. It tries to share all the data structures with the interpreter. I saw some problems with this approach so I stopped it.
• JIT2 is a new approach, it will manage more things on its own and has a different architecture (heap is shared with the interpreter, but registers and some flags are managed internally). JIT2 still is less capable than JIT1.

I also added a JIT CI test (right now, it fails because JIT1 did support more kinds of predicates).

[UWN]

Just a naive question: Have you the possibility to abolish a definition (even if it is static)? The systems that do this correctly are rare (like 1, id est SICStus)

[aarroyoc]

Right now, that's not possible and it is indeed a somewhat difficult problem. Compiled predicates that call other compiled predicates don't check if the later has been abolished. I'll give it some thought

[UWN]

Within ISO, there is only abolish/1to abolish dynamic predicates. SICStus offers the additional functionality to abolish also static predicates with abolish/2 with option force(true). Being able to abolish static code on a predicate-by-predicate basis is a bit much to ask for since this prevents many optimizations. Maybe the granularity could be somewhat coarser. Like the entire Prolog text that was prepared for execution. Or some dependency mechanism. However, if code is abolished it must be conforming to the logical update semantics...

The most important use case is indeed to reload some code.

[UWN]

The most important use case is indeed to reload some code.

And the most important current use case of this would indeed be exhaustive testing. Currently, this does not work for asserta/1 & rectact/1and thus the WAM code generation is not much tested either. Even SICStus had (some time ago) issues there.

[aarroyoc]

I updated the PR, I removed the JIT1, now all the focus is on JIT2, which can only do very basic predicates right now (like a(1,2,3) and query: a(X, Y, Z). But it implements the skeleton of the new architecture, it ships a deref/store implementation in pure CLIF (Cranelift assembly). Everything it's still under a feature flag, so I think it's better to merge it, so code doesn't diverge too much between branches.

[triska]

@aarroyoc: Thank you a lot for working on this extremely impressive feature!

In order to merge this with minimal chance for conflicts with other PRs and existing ongoing developments in other branches, do you think it would be good to reduce the changes to exactly those that should actually be kept, by rebasing the PR and removing features that were only present intermittently, if any?