ExaModels AOT compilation

[sshin23]

In order for ExaModels to be fully ahead-of-time (AOT) compilable without relying on the Julia runtime, several changes would be required. The main items are outlined below.

Make ExaCore immutable and type-stable

Currently, ExaCore stores attributes with abstract types—most notably core.obj and core.con. This prevents full type inference and therefore blocks AOT compilation.

To resolve this, ExaCore should become an immutable struct whose type parameters encode the types of core.obj and core.con. As a consequence, core would need to be rebuilt whenever incremental changes are made.

This implies a change in syntax. For example:

    c = constraint(core, x[i] for i=1:10)   # old
    core, c = constraint(core, x[i] for i=1:10)   # new

If this change is adopted, the old syntax should be deprecated after one major release.

Optionally, we could introduce a higher-level syntax:

    core = ExaCore()

    core, x, y = variables(core, varspec(1:10), varspec(1:5))
    core, c1, c2 = constraints(core, conspec(x[i] for i=1:10), conspec(y[i] for i=1:5))
    core, o1, o2 = objectives(core, objspec(x[i]^2 for i=1:10), objspec(y[i]^2 for i=1:5))

    m = ExaModel(core)

Here, varspec, conspec, and objspec would simply cache their arguments
and internally call variable(…), constraint(…), and objective(…) when
executed within the corresponding variables(…), constraints(…), and
objectives(…) functions.

Make Compressor type-stable

Compressor currently relies on unique! and certain for loops that introduce type instability. These would need to be rewritten to maintain full type stability.

Relax some operator overloading specializations

Some operator overloads are currently overly specialized. For example, expressions such as

    ParSource() + 0

should avoid generating specialized methods. Relaxing these specializations would reduce compilation complexity and improve AOT compatibility.

Proof-of-concept AOT modeling library

Once the above changes are implemented, the next step would be to develop a proof-of-concept AOT-compiled domain-specific modeling library built on ExaModels. This prototype should include:

• a C interface
• a standalone executable
  It is not yet clear how difficult solver integration will be. As an initial target, Ipopt may be a simpler starting point than MadNLP.

cc: @hfytr

[sshin23]

@michel2323 @jbcaillau, in this regard, the LinearAlgebra extension may consider using StaticArrays to make type inference possible. This might be a good thing for users as well, so that this can prevent the user from trying to use the LA extension for problems with large arrays.