Some desirables are not research-interesting, and don't substantially affect the core functionality or performance or reliability of liballocs, but are relatively small changes that could make an outsized difference to the ability of others to pick up liballocs and use it in practical contexts. This meta-issue collects such issues.
To these, I would add the following possible contributions to other codebases:
- contribute a version of liballocs's
dumpallocs.ml allocation site ("sizeofness") analysis to LLVM and/or GCC
- record calls to
__builtin_alloca() in the DWARF generated by LLVM and/or GCC, probably as an inlined_subroutine
... which collectively would enable liballocs to work fully/reliably without the use of a compiler wrapper, given binaries built with these improved compilers.
Some desirables are not research-interesting, and don't substantially affect the core functionality or performance or reliability of liballocs, but are relatively small changes that could make an outsized difference to the ability of others to pick up liballocs and use it in practical contexts. This meta-issue collects such issues.
To these, I would add the following possible contributions to other codebases:
dumpallocs.mlallocation site ("sizeofness") analysis to LLVM and/or GCC__builtin_alloca()in the DWARF generated by LLVM and/or GCC, probably as aninlined_subroutine... which collectively would enable liballocs to work fully/reliably without the use of a compiler wrapper, given binaries built with these improved compilers.