Andy Wingo <wi...@pobox.com> skribis:

> On Mon 06 Jan 2020 10:47, Ludovic Courtès <l...@gnu.org> writes:
>> Andy Wingo <wi...@pobox.com> skribis:
>>> With cross-module inlining of "small" definitions, I think we would
>>> solve a lot of this kind of problem.  I think we could add this during
>>> 3.0 and for this reason I would hesitate to apply this patch for 3.0
>>> because it changes "fx+" exports to be macros rather than "normal"
>>> values in the ABI.  WDYT?
>> I agree that cross-module inlining is the better fix whereas this patch
>> is the immediate workaround.
>> Are you confident that cross-module inlining can happen be added without
>> introducing incompatibilities over in the 3.0 series?  (At first sight
>> it seems tricky to me, notably because we’d have to store Tree-IL in
>> object files, which introduces compatibility and thus external
>> representation versioning considerations.)
> Concretely I would add a little part of the compiler to the Tree-IL
> phase to serialize a bytecode for the "small" definitions in the module,
> for declarative modules, both public and private (because public
> definitions may alias private definitions).  This would be stored as a
> bytevector in an additional field of the module, and the program being
> compiled would be transformed to initialize the "lto" field (placeholder
> name) of the module, so that once the compiled module is loaded, we have
> the inlinable bindings.  I think this can be done compatibly.

OK, sounds great.  What are your thoughts about versioning that wire
Tree-IL representation?

>> If you do, then it’s fine to drop this patch.  If conversely
>> cross-module inlining might take longer, then we can have this patch in
>> and drop it in 3.2.  Your call!  (I guess I’m not being that helpful
>> here.  :-))
> :)
> I hesitate to land this patch because we haven't shown that it
> significantly helps things, it would need to be undone, and it makes the
> ABI more fragile.  So if that's OK let's do nothing :)

Alright, fine with me!


Reply via email to