[vm/ffi] Explore using `FfiNative` for static linking

[dcharkes]

Given a dart file

@FfiNative<Int64 Function(Int64, Int64)>("FfiNative_Sum", isLeaf:true)
external int sum(int a, int b);

main(){
  print(sum(40, 2));
}

And a C file:

#include <stdint.h>

uint64_t FfiNative_Sum(uint64_t a, uint64_t b) { return a + b; }

It should be possible to compile this to a pc relative call if we use the native linker.

1. Compile the dart program to a (a) an assembly file with a call FfiNative_Sum or (b) to an ELF file with relocation records (a static library in ELF format rather than a dynamic library in ELF format).
2. Compile the C program to a relocatable file (static library or object file).
3. Link them together with the native linker to a dynamic library in ELF format.
4. Run with dartaotruntime passing in the dynamic library or appending it.

There is a huge design space.

For example we should add asset tags to disambiguate native symbols.
And we could use the same syntax for dynamic linking using these assets.
I will not write these up here, but wanted to have a bug to point to.

[safasofuoglu]

Would this enable LTO inlining of FfiNative_Sum?

[dcharkes]

Would this enable LTO inlining of FfiNative_Sum?

I believe so.

[mraleph]

Unfortunately, LTO inlining requires some interoperability between compilers (e.g. either us using the same IR as C/C++ compiler or us implementing C/C++ compiler on top of our IR). Currently we have no concrete plans for going that route.

The best we will get here is a direct (e.g. PC-relative) call from Dart function to C function, but not the inlining of C function into the Dart function.

If you have some C code that is so small that it hugely benefits from inlining into its Dart caller then probably that C code should be written in Dart if possible. Though, I can understand situations where callee is extremely low level (e.g. a snippet of assembly code). I have been dreaming about adding inline assembly to dart:ffi - but that's a very speculative and probably far out, given our current priorities.

[dcharkes]

Unfortunately, LTO inlining requires some interoperability between compilers (e.g. either us using the same IR as C/C++ compiler or us implementing C/C++ compiler on top of our IR).

Today I learned, with LTO a higher level representation (LLVM bitcode) is put in object files, not ELF:

• https://llvm.org/docs/LinkTimeOptimization.html
• https://developer.arm.com/documentation/101458/2200/Optimize/Link-Time-Optimization--LTO-/What-is-Link-Time-Optimization--LTO-#:~:text=Link%20Time%20Optimization%20is%20a,them%20to%20form%20the%20executable.

(I assumed LTO works on regular ELF object files and static libraries. ELF object files and static libraries only contain symbols and machine code, not a higher level representation. In which case LTO would need to prove to itself which registers are preserved to enable inlining.)