Over the last few weeks, I've been working on adding Racket to Compiler Explorer (sometimes called Godbolt because of the domain name which is also the creator's last name).
If you've never encountered it before, Compiler Explorer is a multi-language playground aimed at advanced users and language toolchain developers who want to inspect how bits of source code along with various optimisation flags affect the assembly produced by the toolchain. It can also be useful to learn more about how language implementations work by seeing what they do with different inputs.
Basic support for Racket is now available showing the decompiled assembly for your code input.
Please let me know if you find this useful!
Potential enhancements
There are quite a few further enhancements I can imagine already, and I've listed a few below. You may have others, so feel free to share them here. I'd like to focus my efforts on features that resonate with others in the community, so it helps a lot to hear which are most interesting to you.
Each enhancement idea is in a separate reply below, so you can like / heart them individually if they resonate with you.
Other playgrounds
There are various general purpose playgrounds for Racket already. Compiler Explorer support is (primarily) aimed at the specialised use case of toolchain / program inspection instead of general execution.
PLT_* environment variables in optimisation flags input
Many of Racket's internal flags aimed at Racket developers are controlled via PLT_* environment variables. Compiler Explorer's optimisation flags input only handles regular program arguments which are fed to raco make, so we'd need to specialise this to handle environment variables as well.
Some toolchains emit debug info which can be used to visually link source code lines to their corresponding lines in the emitted assembly. Compiler Explorer uses this info when you hover on lines from toolchains that support it (e.g. Clang).
For Racket, I expect this would be fairly tricky to achieve currently, since AFAIK source line numbers are not carried all the way down to the assembly level today. As a Racket user, there are debugging facilities based around errortrace, but that info only exists at the Racket language level. I may have totally misunderstood though, so please let me know if I have!
Few of the PLT_ flags control optimization. Are there particular ones you are interested in?
For correlating to source lines, I think this would be a really big win for Racket, but is as you say a significant challenge. A lot of infrastructure is already there to do this, but it would take significant integration work. I think there are two major ways you could go about this:
Emitting debug information using an existing format (eg DWARF).
Printing out something along with the assembly code and then correlating that back.
The second would probably be less work in Chez Scheme itself but more work in the external tooling and is probably where I would start.
Ah yeah, I guess most of them are for printing diagnostic output, like PLT_LINKLET_SHOW and friends. I may have mentally bucketed the CS Compilation Modes as controlling "optimisation", but after looking again, those are mainly selecting e.g. interpreter vs. machine code and such.
Are there other optimisation settings that would be interesting to try?
Even if they aren't really about optimisation, it may still be convenient to wire up the PLT_* flags on Compiler Explorer, as there's a button to show the output the toolchain printed during compilation. This could be used as a cheap way of viewing things like the PLT_LINKLET_SHOW output until a more polished UI is added.
Thanks for these hints! It helps to have confirmation that my (very rough) understanding of Racket's debug info handling was mostly correct.
My ongoing research is focused on reliable debug info, and I think it could be quite fun to add some level of debug info support to Racket, so I'll keep exploring what's possible here. I'd really like to try aiming for stronger guarantees of debug info correctness than you typically get with other toolchains, but perhaps I should start with making a basic version work first.
