Enable ClangIR generation for very simple functions. The functions have
to return `void` or an integral type, contain only compound statements
or `return` statements, and `return` statement expressions can only be
integral literals of the correct type. The functions can have
parameters, but those are currently ignored because there is no way to
access them.
This change intentionally focuses on breadth (introducing scopes,
statements, and expressions) rather than depth, because it enables
people to work on upstreaming in parallel without interference.
The new ClangIR ops in this change are `ReturnOp`, `YieldOp`, `ScopeOp`,
and `TrapOp`. These operations are complete (except for the
`ParentOneOf` property) and shouldn't require further upstreaming
changes. Significant additions were made to `FuncOp`, adding a type and
a region, but that operation is still far from complete.
The classes `ScalarExprEmitter` and `CIRGenFunction`, along with the
`emit*` functions in `CIRGenFunction` that generate ClangIR for
statements, are new in this change. All of these are very incomplete and
will be filled out in later upstreaming patches.
Existing test `hello.c` is removed and replaced by the new test
`func-simple.cpp`. This tests all forms of functions that are currently
supported.
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.
This change introduces lowering from CIR to LLVM IR of global integer
and floating-point variables, using defaults for attributes that aren't yet
implemented.
This adds a .clang-tidy file to the clang/lib/CIR/FrontendAction
directory, moves and updates the incorrectly located
include/clang/CIR/FrontendAction .clang-tidy file, and updates two files
from a recent commit to bring them into conformance with previously
agreed upon rules for where to use LLVM naming conventions and where to
use MLIR naming conventions.
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.
Upstream several ClangIR-specific MLIR attributes, in particular
attributes for integer, floating-point, and null pointer constants.
These are the first ClangIR attributes to be upstreamed, so
infrastructure changes are included, such as the table-gen file
`CIRAttrs.td`.
Attributes can be used as the initial values for global variables. The
existing automated test global-var-simple.cpp includes initial values
for some of the global variables in the test.
Upstream ClangIR support for `void` type, floating-point types, pointer
types, and function types.
Floating-point support is missing the IBM double-double format, because
that hasn't been implemented in the incubator project yet.
Pointer types do not yet support address spaces.
Function type support includes only the return type and the parameter
types. The many other properties and attributes of function types will
be upstreamed later.
ClangIR CodeGen code uses both `mlir::MLIRContext` and
`clang::ASTContext` objects extensively. Refering to either of those as
just "context" can be confusing.
Change the names of all variables, parameters, and fields in
`clang/lib/CIR/CodeGen` that refer to `MLIRContext` or an `ASTContext`
to be either `mlirContext` or `astContext`.
This change is only the renaming of variables/parameters/fields. There
are no behavior changes. So there are no new tests or changes to
existing tests. This change mimics a recent change in the ClangIR
incubator repository.
Small infrastructure and background changes to ClangIR.
Create class `CIRGenBuilderTy` and its base class `CIRBaseBuilderTy`.
These are mostly empty for now, except for what is inherited from
`mlir::OpBuilder`. But they will fill up quickly as more ClangIR code
gen is upstreamed. `CIRGenModule` and `CIRGenTypes` are changed to use
`CIRGenBuilderTy`.
Add cached types to struct `CIRGenTypeCache` for the integral types that
are currently supported. Initialize those cached types in the
`CIRGenModule` constructor. The first uses of those types (well, one of
them) is in `CIRGenTypes::convertType`.
Have `CIRGenTypes::convertType` cache its results in a map from
`clang::Type` to `mlir::Type`, saving it from having to convert the same
type again and again.
There are no new tests or changed tests in this commit. There are no
changes to behavior, just improvements to how the existing behavior is
implemented.
Add integral types to ClangIR. These are the first ClangIR types, so the
change includes some infrastructure for managing ClangIR types.
So that the integral types can be used somewhere, generate ClangIR for
global variables using the new `cir.global` op. As with the current
support for functions, global variables are just a stub at the moment.
The only properties that global variables have are a name and a type.
Add a new ClangIR code gen test global-var-simple.cpp, which defines
global variables with most of the integral types.
(Part of upstreaming the ClangIR incubator project into LLVM.)
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.
Building `MLIRCIR` will report an error `CIROpsDialect.h.inc` not found.
This is because `MLIRCIR` hasn't declared its dependence on the tablegen
target `MLIRCIROpsIncGen`. This patch fixes the issue.
The buildX naming convention originated when the CIRGen implementation
was planned to be substantially different from original CodeGen. CIRGen
is now a much closer adaption of CodeGen, and the emitX to buildX
renaming just makes things more confusing, since CodeGen also has some
helper functions whose names start with build or Build, so it's not
immediately clear which CodeGen function corresponds to a CIRGen buildX
function. Rename the buildX functions back to emitX to fix this.
https://github.com/llvm/clangir/issues/1025 discusses the motivation.
The mechanical parts of this change were done via:
find clang \( -name '*.h' -o -name '*.cpp' -o -name '*.td' \) -print0 |
xargs -0 perl -pi -e 's/mlir::cir/cir/g'
find clang \( -name '*.h' -o -name '*.cpp' \) -print0 | xargs -0 perl
-pi -e 's/::cir/cir/g'
There were some manual fixups and a clang-format run afterwards.
https://github.com/llvm/clangir/issues/1025 explains why we want to move
the CIR dialect from the `mlir::cir` to the `cir` namespace. To avoid
overloading the `cir` namespace too much afterwards, move all symbols
whose equivalents live inside the `clang::CodeGen` namespace to a new
`clang::CIRGen` namespace, so that we match the original CodeGen's
structure more closely.
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
This adds no real content, it just incrementally adds some scaffolding
necessary to enable a future patch to just add our first few ops.
Test Plan:
```
$ cmake -Sllvm -Bbuild -DCLANG_ENABLE_CIR=1 \
-DLLVM_ENABLE_PROJECTS='clang;mlir' \
-DCMAKE_BUILD_TYPE=Release -GNinja
$ ninja -C build check-clang
$ ninja -C build MLIRCIROpsIncGen
$ ninja -C build MLIRCIR
```
Reviewers: AaronBallman, erichkeane, bcardosolopes
Reviewed By: erichkeane, AaronBallman, bcardosolopes
Pull Request: https://github.com/llvm/llvm-project/pull/86080
Introduce a cmake variable that guards the inclusion of ClangIR into the
build of clang. Guard that we aren't trying to build without MLIR. Add
two subdirectories that, as of now, don't do anything.
Reviewers: bcardosolopes, erichkeane, petrhosek, Ericson2314
Reviewed By: bcardosolopes
Pull Request: https://github.com/llvm/llvm-project/pull/86078
