"Delayed" Calls and trimming

[gbaraldi]

One of the missing features around trimming currently is what I'm calling "delayed" calls. Basically operations that mean that a call will be performed using a specificic signature, but instead of going through the typical Expr(:invoke path, they might happen eventually.

An incomplete list of operations is

• cfunction
• tasks
• Opaque Closures
• atexit
• Finalizers

They all could be represented by something like a :virtual_invoke, which serves just as a token that indicates to typeinf_ext_toplevel/create_native that code must be compiled for those code_instances. ccallable is already an example of a delayed call, but it's more well behaved since it depends only on function definitions

[topolarity]

A challenge with the proposal is that we need a way to associate this with the original primitive. so that --trim verification can know the dispatch was resolved.

Otherwise, how do I know that

   Expr(:virtual_invoke, #= ... =#)
   Expr(:call, Core.finalizer, #= ... =#)

is a resolved version of that finalizer call?

This could instead be two finalizer calls, one of which was resolved and then deleted due to, e.g., effects analysis and another which we neither resolved nor deleted.

[vchuravy]

Why do we need a new IR statement? Wouldn't it be enough for the interpreter to recognize these constructs?

TKF and I did this for tasks.

[gbaraldi]

Im not attached to that other expr at all to be clear, I think there are other options, we can bundle it to specific other stmts kind of like the ccall op bundle or any other suggestion actually