# Racket now available on Compiler Explorer

**URL:** <https://racket.discourse.group/t/racket-now-available-on-compiler-explorer/1356>\
**Category:** Show & Tell\
**Tags:** developer-tools, internals\
**Created:** [October 7, 2022, 3:20pm UTC](https://racket.discourse.group/t/racket-now-available-on-compiler-explorer/1356 "2022-10-07T15:20:52Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\
**Post date:** [October 7, 2022, 5:25pm UTC](https://racket.discourse.group/t/racket-now-available-on-compiler-explorer/1356/8 "2022-10-07T17:25:05Z")

</div>

> [@samth](#):
>
> Few of the `PLT_` flags control optimization. Are there particular ones you are interested in?

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](https://docs.racket-lang.org/reference/compiler.html#%28part._cs-compiler-modes%29) 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.

> [@samth](#):
>
> 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.

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](https://convolv.es/talks/testing-debug-info/) 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. 😇

---

_[View the full topic](https://racket.discourse.group/t/racket-now-available-on-compiler-explorer/1356)._
