mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 22:02:23 +01:00
David Blaikie
f1f6005d4a
Background: https://docs.google.com/document/d/1wi85FRiWh4X9A-gCYMVGKR40-q5fM6-3JaSpePk-XCY/edit?usp=sharing And specifically this work is essentially an alternative to #5543 Clang's code generation is implemented through an ASTListener (clang::CodeGenerator) that is attached throughout Clang's parsing/sema/code generation phases and acts on Clang AST incrementally throughout that process. Prior to this patch, Carbon has only created the CodeGenerator during Carbon's `lower` phase, missing out on key callbacks that would be made by Clang during `check`. Some of these issues were addressed by #6237 and #6483 - but there were still remaining cases where the delayed processing lead to missing functionality. With #6483 much of the Clang code that made multithreaded complexity of #5543 is no longer present, and we have access to the point of ASTListener registration so we can register the CodeGenerator there and consume its resulting llvm::Module during lower. Examples of some of the bugs this addresses are seen in the linked doc, and checked in as tests in this change in `clang_code_generator_callbacks.carbon` An indicental bug that's also fixed, and caused all the other test case churn, is that the `CodeGenerator` created during `lower` wasn't getting passed the Clang `CodeGenOpts` and was creating its own default - so, most notably, optimization flags were not respected. This meant that the LLVM IR from Clang was always -O0 style IR (optnone, no inlinehint, no TBAA, etc). With this change, now the Clang IRGen gets the real `CodeGenOpts` and respects optimization/other flags specified there. This is only meant to be a rough proof of concept - I'm totally open to reworking this in any way (even quite substantially) if folks have ideas about how this should be implemented most generally/elegantly/etc.