Support cross compile for LLVM backend

[xofyarg]

Motivation

When having multiple places running the same module, depends on the scale, it would save lots of CPU cycles if precompiled module is distributed instead of wasm code.

Proposed solution

Add an API to be able to override target triple/cpu/features when create target machine.

[nlewycky]

Yes, cross-compilation is a great idea and we'd love to support it. Thank you for getting this started!

Really there's two issues here, one is supporting cross-compilation, but the other is supporting precompilation and loading precompiled code, even on the same target. Depending on how you design it, cross-compilation probably isn't useful unless you can load precompiled code on the other machine with the other architecture?

I said it's dependent on the design, for instance LLVM ORC JIT has a networked mode where you can request cross-compiled code over the network, in which case we wouldn't be precompiling, per se.

Let's make sure we agree on an overall plan so that you don't spend time preparing PRs only to discover that we want a different design.

As a first draft, how about this:

• We re-use "wasmer cache" format for saving down files and loading them up. (In particular, we don't build standalone executables out of the .wasm file, and we don't try to emit native object files that the native linker can link against, we don't use ORC JIT networking fanciness.)
• We need to add new commands to the wasmer program. The ability to compile a file and cache the result but not run it, the ability to pull out a cached entry and copy it to a file that can be moved to another machine, the ability to insert a cache entry on that other machine, and finally a flag the type of target machine. The target is added to cache key.
• Currently Wasmer+LLVM doesn't support running on anything except x86-64, so for now let's add the ability to target different micro-architectures of x86-64. That's partially enabled by your PR Enable compilation for specific target #964, a future PR can thread it through to the command-line.

Other backends should be able to implement this same interface. Over time I'd like to minimize the difference in features between the different backends.

[xofyarg]

Let's make sure we agree on an overall plan

Yes, that's my intention. Thanks for the breakdown.

As you mentioned, I think using wasmer cache format and focus on x86-64 is a good scope, it can keep things simple to adopt and test. In our use case, we are having issue to use module cache compiled by a different host with different CPU feature flag.

[syrusakbary]

This is done in the refactor. Will close the issue once it lands in master.

[syrusakbary]

Thanks to the refactor we now support cross compilation to different architectures.

wasmer compile python.wasm -o python.so --native --target=aarch64-linux-gnu

And then, in the aarch64:

wasmer run python.so