How an Optimizing Compiler Works

Re:How an Optimizing Compiler Works by bjoli on Monday November 11, 2019 @04:53PM (#21509292)

That is one thing I sorely miss in languages that aren't lisps. The first optimizer pass is source->source. In guile I do

    ,opt expression

And it prints the source code after a first basic pass of the expander and optimizer. It does constant folding, inlining, dead code elimination and partial evaluation (and some other things). Being able to inspect what guile does helps a lot with macro writing, and is just a generally handy tool.

It beats reading assembly (which is also available) any day of the week.

[ Parent | on HN ]

Re:How an Optimizing Compiler Works by nothrabannosir on Monday November 11, 2019 @06:20PM (#21509998)

Scala has well documented compiler passes which act on the full AST, so they're also source -> source. You can print the AST after any pass, using a command line flag. It's not as easy as a Lisp, but useful when you're working on a compiler plugin or extension.

[ Parent | on HN ]

Re:How an Optimizing Compiler Works by bjoli on Tuesday November 12, 2019 @07:12AM (#21513453)

The thing with guile is that it is already an AST, so the code ,opt outputs is still valid guile.

[ Parent | on HN ]

Re:How an Optimizing Compiler Works by chrisseaton on Monday November 11, 2019 @07:51PM (#21510481)

How does it do source-to-source while maintaining debug-ability? If the result of your partial evaluation is source code that is run then what happens when I set a breakpoint on a line that has been partially evaluated away? Is there some metadata that is produced alongside the source to allow that breakpoint to be applied to the code that has been optimized away and how does that work?

This is why optimisations aren't usually source-to-source - they need to include in the output extra information that isn't normally representable in source code. Another reason is that compiling to a lower-level representation gives you more power - when I partially evaluate I gain extra information such as that an add operator will not overflow, and I want to include that valuable information in my output even if there is no no-overflow add operator in the source language.

[ Parent | on HN ]

Re:How an Optimizing Compiler Works by bjoli on Tuesday November 12, 2019 @12:27AM (#21511756)

This is not done over regular lisp lists, but over scheme syntax objects that retain the original source info.

Those syntax objects are also the basis of the hygienic macro systems in many schemes (at least ones using syntax-case) so that macros also benefit from that information.

The lisp source representation is already an AST, so these kinds of transformations are trivial.

[ Parent | on HN ]

Re:How an Optimizing Compiler Works by wtetzner on Tuesday November 12, 2019 @09:19AM (#21514254)

Just having support for a textual representation of the intermediate languages that is easily human readable would probably be good enough. It would let you inspect the intermediate steps. The source info that's tracked could be omitted in the printed representation, even though it still exists in the in-memory representation.

[ Parent | on HN ]