A couple of handlers that were missing from the CIRGenerator AST visitor
allowed important features to be silently ignored during CIR generation.
This change adds these handlers with diagnostics to report that they are
not yet handled (except in the case where only debug information is
missed).
This change upstreams the code to support emitting inline C++ function
definitions, including the ASTConsumer handler for inline definitions
and the code to load the 'this' pointer.
This necessitates introducing the Itanium CXXABI class. No other CXXABI
subclasses are supported at this time. The Itanium CXXABI is used for
AppleARM64, which will require its own handler for a few special cases
(such as array cookies) later.
This change adds code to defer emitting declarations and tentative
definitions until they are referenced or trigger by a call to
CompleteTentativeDefinition. This is needed to avoid premature handling
of declarations and definitions that might not be referenced in the
current translation unit. It also avoids incorrectly adding an
initializer to external declarations.
This change also updates the way the insertion location for globals is
chosen so that all globals will be emitted together at the top of the
module. This makes no functional difference, but it is very useful for
writing sensible tests.
Some tests are modified in this change to reorder global variables so
that they can be checked in the order in which they will be emitted.
This patch adds the cir-simplify pass for SelectOp and TernaryOp. It
also adds the SelectOp folder and adds the constant materializer for the
CIR dialect.
This change introduces the cir-canonicalize pass. This is a simple
cir-to-cir transformation that eliminates empty scopes and redundant
branches. It will be expanded in future changes to simplify other
redundant instruction sequences.
MLIR verification and mlir-specific command-line option handling is also
introduced here.
Add frontend actions to support emitting assembly, bitcode, and object
files when compiling with ClangIR. This change also correctly sets and
propagates the target triple in the MLIR and LLVM modules, which was a
necessary prerequisite for emitting assembly and object files.
Create the skeleton framework for lowering from ClangIR to LLVM IR. This
initial implementation just creates an empty LLVM IR module. Actual
lowering of even minimal ClangIR is deferred to a later patch.
Fix a compiler warning in `CIRGenConsumer::HandleTranslationUnit` in
`clang/lib/CIR/FrontendAction/CIRGenAction.cpp`. The warning was about a
`default:` section in a switch statement that already covered all the
values of an enum. Delete the `default:` section.
Finish hooking up ClangIR code gen into the Clang control flow,
initializing enough that basic code gen is possible.
Add an almost empty `cir.func` op to the ClangIR dialect. Currently the
only property of the function is its name. Add the code necessary to
code gen a cir.func op.
Create essentially empty files
clang/lib/CIR/Dialect/IR/{CIRAttrs.cpp,CIRTypes.cpp}. These will be
filled in later as attributes and types are defined in the ClangIR
dialect.
(Part of upstreaming the ClangIR incubator project into LLVM.)
Build out the necessary infrastructure for the main entry point into
ClangIR generation -- CIRGenModule. A set of boilerplate classes exist
to facilitate this -- CIRGenerator, CIRGenAction, EmitCIRAction and
CIRGenConsumer. These all mirror the corresponding types from LLVM
generation by Clang's CodeGen.
The main entry point to CIR generation is
`CIRGenModule::buildTopLevelDecl`. It is currently just an empty
function. We've added a test to ensure that the pipeline reaches this
point and doesn't fail, but does nothing else. This will be removed in
one of the subsequent patches that'll add basic `cir.func` emission.
This patch also re-adds `-emit-cir` to the driver. lib/Driver/Driver.cpp
requires that a driver flag exists to facilirate the selection of the
right actions for the driver to create. Without a driver flag you get
the standard behaviors of `-S`, `-c`, etc. If we want to emit CIR IR
and, eventually, bytecode we'll need a driver flag to force this. This
is why `-emit-llvm` is a driver flag. Notably, `-emit-llvm-bc` as a cc1
flag doesn't ever do the right thing. Without a driver flag it is
incorrectly ignored and an executable is emitted. With `-S` a file named
`something.s` is emitted which actually contains bitcode.
Reviewers: AaronBallman, MaskRay, bcardosolopes
Reviewed By: bcardosolopes, AaronBallman
Pull Request: https://github.com/llvm/llvm-project/pull/91007
