Hi! 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! Thanks, Ludo’.