Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: add a README section on developing the compiler #30074
For example, such a section could mention:
Anything else that comes to mind, please add it to this issue. I plan on sending a CL to add a markdown section sometime during the 1.13 cycle.
I realise the SSA package has lots of extra checks and debugging flags one can enable, but I think those should be covered by
Maybe references to gosmith and how to fuzz the compiler and how to build and run a race-enabled compiler. Mention the SSA rulelog? Some basic tips (like start with the simplest possible reproduction and understand exactly what is happening with it). Pointers on where all the tests live (some in-package, some over in the test dir).
Hmm, I've personally found it a bit unnecessary. What I do is always run
Not exactly the same, as toolstash-check compares with the direct parent, but close enough :)
I think it would need documentation if we are to suggest it here :)
I worry that these would be a bit too advanced for the "modifying the compiler" intro section. We don't want to bombard new developers with two pages of tools to learn. Perhaps this could fall under a more advanced section.
Sure, but wouldn't this go in the SSA readme?
Good ideas! I was forgetting about the simpler pieces of advice like these.
Here's another idea: How to measure whether a compiler patch produces smaller binaries. For example, if the prove pass is made a bit smarter, and we want to check that it's really removing many bounds checks from a large binary.
I believe this is usually measured by comparing text section sizes between two built binaries, but I'm not sure what the tips for this are. For example:
It helps prevent making silly mistakes, which I have personally done more than I care to recount. Also, it makes it easy to check all platforms, which matters sometimes.
Yes. Mea culpa. Although FWIW most folks I have recommended it to (on CLs/issues) figure it out pretty readily. It could also use a bit of cleanup.
I have also long had plans to unify some of the toolchain-wranging in compilecmp and toolstash-check and pull it into a re-usable package. I have some of it written, but never finished it.
compilecmp does a fair amount of this already. If you pass it
For rapid development, I usually just
Since it builds in /tmp, you can also check multiple CLs in parallel. And like @josharian mentioned, it can help checking other platforms too.
FWIW, I usually use
Some other things to mention: how to inspect various stages of the compiler. For example, using -S to dump assembly output; GOSSAFUNC to dump SSA stuff; -W to dump the typechecked trees; etc.