Platform for unverified assembly-level experiments

[sorear]

trafficstars

We would like to be able to modify IRs at various levels to simulate the effects of a compiler change. In most cases the plumbing for this would be very difficult, but labLang is nearly identical in scope to a traditional assembly language and it would be possible to dump labLang as editable assembly in arch-specific syntax.

Have a theory that the garbage collector is slow because it copies one word at a time? Make some changes in _Gc and see what happens.

Want to do rough call-stack profiling, but debug information isn't even on the roadmap yet? Calls and returns are easy to pattern match at this point, the dumper could have a feature to maintain a C-compatible shadow stack.

Want to recognize allocation sites and add a tracepoint? Also doable.

My initial plan is an unverified SML program which parses --explore output and translates the labLang JSON dump into assembly syntax, initially x64 only but with allowance for other targets, probably also with a hook in compilationLib. There's an argument to be made for better integration with the bootstrapped compiler but I don't want to pay the size and bootstrapping time cost there.

Since this is duplicating encoder logic there's some potential to get out of sync with the encoder used for normal compilation. Hopefully won't be an issue.

[ColinGilbert]

Would it be feasible to separate the encoder logic (or parts of it) into a separate, callable library? In your opinion(s), how well is this code base already split into components with a single responsibility each? If not, would hygienic activities aimed at achieving such a state be worth doing?

I discuss this because @sorear mentioned that fulfilling this task would require duplicating encoder logic... Is this really necessary due to domain-specific restrictions, or it be a quick workaround to a more fundamental problem? I really love your project so please don't take it the wrong way, but that smelled a touch like the code-base might be nearing a state of runaway exploratory development; it might be in need of cleanup in order to ease further progress. If I am incorrect for fundamental reasons please disregard me, as your experience in writing compilers far outstrips mine. However, if refactoring happens to be something that needs doing, I'd be pleased to try my hand at it!