[CIR] Cleanup: mlirContext and astContext (#119450)

ClangIR CodeGen code uses both `mlir::MLIRContext` and
`clang::ASTContext` objects extensively. Refering to either of those as
just "context" ca

[CIR] Cleanup: mlirContext and astContext (#119450)

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.

show more ...

[CIR] Infrastructure: class CIRGenBuilderTy; cache CIR types (#119037)

Small infrastructure and background changes to ClangIR.

Create class `CIRGenBuilderTy` and its base class `CIRBaseBuilderTy`

[CIR] Infrastructure: class CIRGenBuilderTy; cache CIR types (#119037)

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.

show more ...

[CIR] Integral types; simple global variables (#118743)

Add integral types to ClangIR. These are the first ClangIR types, so the
change includes some infrastructure for managing ClangIR types.

S

[CIR] Integral types; simple global variables (#118743)

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.)

show more ...

[clang][CIR] Change buildX functions to emitX (#115568)

The buildX naming convention originated when the CIRGen implementation
was planned to be substantially different from original CodeGen. CIRGe

[clang][CIR] Change buildX functions to emitX (#115568)

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.

show more ...

[clang][CIR] Move CIRGen types into clang::CIRGen (#115385)

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

[clang][CIR] Move CIRGen types into clang::CIRGen (#115385)

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.

show more ...

[CIR] Call code gen; create empty cir.func op (#113483)

Finish hooking up ClangIR code gen into the Clang control flow,
initializing enough that basic code gen is possible.

Add an almost empty `

[CIR] Call code gen; create empty cir.func op (#113483)

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.)

show more ...

[CIR] Build out AST consumer patterns to reach the entry point into CIRGen

Build out the necessary infrastructure for the main entry point into
ClangIR generation -- CIRGenModule. A set of boilerpla

[CIR] Build out AST consumer patterns to reach the entry point into CIRGen

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

show more ...