Conversation

The "ML" really means "multi level". This might make it easier to build compilers with tailored IRs and deeper optimization pipelines, similar to what Rust and Swift have

Quote Tweet

Mehdi Amini

@JokerEph

Apr 3, 2019

The Google MLIR team is happy to release MLIR Core as open source: a new multi-level IR compiler framework! Check it out: github.com/tensorflow/mlir More information with two talks at EuroLLVM next Monday, stay tuned!

Joe Groff

@jckarter

Apr 5, 2019

The inner contrarian in me wonders whether language design is due for a NetBurst moment when we all realize deep pipelines are bad and go back to simpler single pass compilable languages

@rf

Apr 5, 2019

Replying to

@jckarter

if we're talkin' strange timelines: ship everything at -O1 and have a JIT infrastructure that can build and drop in the -O3 version using runtime feedback on where dynamic calls land etc. (kinda like .NET NGEN, but starting from a language made for AOT)

Replying to

That's roughly where we want to end up with Swift some day

Replying to

and

Android has this kind of compilation stack for code targeting the Android Runtime (ART). Historically they moved from an interpreter to interpreter + JIT to near full AOT compilation (interpreter still used for one-time init and dynamic code) before arriving at the current model.

Replying to

and

The interpreter / JIT compilation mode generates profiles used to identify the hot code for profile-guided AOT compilation in the background. This is aided by updates being performed in the background since the AOT compilation is redone without any wait (source.android.com/devices/tech/o).

Replying to

and

The JIT compiler can do some low-level tricks and optimizations that an AOT compiler cannot, so it still has a purpose once code has been AOT compiled. There are also a lot of options for configuring how this works. Can still use near full AOT compilation or full AOT compilation.

Replying to

and

There's partial documentation on this here: source.android.com/devices/tech/d For example, I use the near full AOT compilation mode ('speed') without JIT or profiling: github.com/GrapheneOS/pla Full AOT compilation mode (disabling heuristics for interpreting cold code) is 'everything'.

source.android.com

Configuring ART | Android Open Source Project

Replying to

and

They've also done some interesting optimizations, most of which I need to disable for my work. You may know that it spawns apps by forking from a Zygote acting as a template with the common classes / libraries already loaded and initialized, a preloaded OpenGL context and so on.

Replying to

and

They also have some weird optimizations like shared RELRO sections and pre-generating the heaps for libraries, not just the code. I think the way it works is they load them up in a deterministic environment and then write out the heap in a way that's quick to verify on boot.

1:00 AM · Apr 6, 2019Twitter Web Client

Replying to

and

That sounds a lot like what Darwin does with the shared cache, to prelink the system dylibs into one image, pre-bind ObjC and Swift runtime data structures, etc., though we're starting from already native code

Replying to

and

The shared RELRO thing is for native libraries / executables, specifically Chromium, since the library gets mapped in all of the Chromium renderer sandbox processes which are also spawned for every app using the WebView. There's actually a separate WebView sandbox Zygote now.

Show replies