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.
Section merging can increase section alignment after potential spill
sections are created. Since this operation is never performed on spill
sections, they can keep their earlier, smaller, alignment, which
produces a misalignment if a spill occurs.
This change propagates alignment increases forward after merging.
Support HLSL SV_GroupThreadId attribute.
For `directx` target, translate it into `dx.thread.id.in.group` in clang
codeGen and lower `dx.thread.id.in.group` to `dx.op.threadIdInGroup` in
LLVM DirectX backend.
For `spir-v` target, translate it into `spv.thread.id.in.group` in clang
codeGen and lower `spv.thread.id.in.group` to a `LocalInvocationId`
builtin variable in LLVM SPIR-V backend.
Fixes: #70122
Add the `dump_at_exit` flag to control whether or not profiles should be
dumped when the program exits. Since we can call
`__memprof_profile_dump()` directly, we don't necessarily need to dump
profiles at exit.
Fixes:
ERROR: The project you're trying to build requires Bazel 7.3.0
(specified
in llvm-project/utils/bazel/.bazelversion), but it wasn't found in
/usr/bin.
You can install the required Bazel version via apt:
sudo apt update && sudo apt install bazel-7.3.0
If this doesn't work, check Bazel's installation instructions for help:
https://bazel.build/install/ubuntu
Link: https://blog.bazel.build/2024/12/09/bazel-8-release.html
bcmp, bcopy, and bzero should be moved from libc/src/string/ to
lib/src/strings/ in order for docgen to use existing conventions to find
whether we implement a function or not.
We should add support to docgen for mentioning glibc extensions (mempcpy) or
extensions from other libcs.
Although the ABI (if one exists) doesn’t explicitly prohibit
cross-code-object function calls—particularly since our loader can
handle them—such calls are not actually allowed in any of the officially
supported programming models. However, this limitation has some nuances.
For instance, the loader can handle cross-code-object global variables,
which complicates the situation further.
Given this complexity, assuming a closed-world model at link time isn’t
always safe. To address this, this PR introduces an option that enables
this assumption, providing end users the flexibility to enable it for
improved compiler optimizations. However, it is the user’s
responsibility to ensure they do not violate this assumption.
cc1a2ea61e3f8e790125b10d9ec4e7d179156ddf adds a test which can fail if
the output directory is not writeable. Following the pattern of other
tests in this package, use `-o -` to print the IR to stdout instead of
to a file.
For the call to _FortranACUFLaunchKernel, we store the pointer to a
member of a temporary structure in a parameter array. However, when we
obtain an element pointer from the parameter array, its address is
calculated based on the type of the structure. This PR properly treats
the parameter array as an array of pointers.
Example:
```mlir
%30 = llvm.load %29 : !llvm.ptr -> i32
%31 = llvm.mlir.constant(1 : i32) : i32
%32 = llvm.alloca %31 x !llvm.struct<(i64, i64, i32, ptr)> : (i32) -> !llvm.ptr
%33 = llvm.mlir.constant(4 : i32) : i32
%34 = llvm.alloca %33 x !llvm.ptr : (i32) -> !llvm.ptr
%35 = llvm.mlir.constant(0 : i32) : i32
%36 = llvm.getelementptr %32[%35] : (!llvm.ptr, i32) -> !llvm.ptr, !llvm.struct<(i64, i64, i32, ptr)>
llvm.store %8, %36 : i64, !llvm.ptr
%37 = llvm.getelementptr %34[%35] : (!llvm.ptr, i32) -> !llvm.ptr, !llvm.struct<(i64, i64, i32, ptr)>
llvm.store %36, %37 : !llvm.ptr, !llvm.ptr
...
llvm.call @_FortranACUFLaunchKernel(%47, %8, %8, %8, %2, %8, %8, %7, %34, %48) : (!llvm.ptr, i64, i64, i64, i64, i64, i64, i32, !llvm.ptr, !llvm.ptr) -> ()
```
In this example, `%37 = llvm.getelementptr %34[%35] : (!llvm.ptr, i32)
-> !llvm.ptr, !llvm.struct<(i64, i64, i32, ptr)>` will be `%37 =
llvm.getelementptr %34[%35] : (!llvm.ptr, i32) -> !llvm.ptr, !llvm.ptr`.
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.
The only difference is the usage of `JobAction* JA` versus `Action* A`
in one argument, but `JA = cast<JobAction>(A)`, and the called function
is inherited from `Action`.
This PR changes how target extension types are printed when they are
emitted as IR.
This prevents repetitive phrases like "struct = type {...}" from being
repeated over and over in the outputted IR.
Additionally, it should allow opt to not crash when parsing the DXIL
output.
Fixes [#114131](https://github.com/llvm/llvm-project/issues/114131)
When checking for the poison elements in the matches node, need to
consider the register number, when clearing the corresponding mask
element.
Fixes#119393
Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.
Add support for type summaries embedded into the binary.
These embedded summaries will typically be generated by Swift macros,
but can also be generated by any other means.
rdar://115184658
This PR adds default option below. The new options will come as default
to true and not change the original lowering behavior of pack and unpack
op.
- lowerPadLikeWithInsertSlice to packOp (with default = true)
- lowerUnpadLikeWithExtractSlice to unPackOp (with default = true)
The motivation of the PR is finer granular control of the lowering of
pack and unpack Ops. This is useful in particular when we want to
guarantee that there's no additional insertslice and extractslice that
interfere with tiling. With the original lowering pipeline, packOp and
unPackOp may be lowered to insertslice and extractslice when the high
dimensions are unit dimensions and no transpose is invovled. Under such
circumstances, such insert and extract slice ops will block
producer/consumer fusion tile + fuse transforms. With this PR, we will
be able to disable such lowering path and allow consumer fusion to go
through as expected.
Update root file in DWARF file/line table as soon as we see the first
"#line" directive.
This was moved from "enabledGenDwarfForAssembly", which is called right
before we emit DWARF information. But if the file is empty or contains
expressions that doesn't need DWARF, it is never called, leaving an
original root file and not the file in the "#line" directive.
Add a test checking for this case.
Fixes: #119020
A linkonce_odr definition can be omitted in LTO compilation if
`canBeOmittedFromSymbolTable()` is true in all bitcode files.
Test more linkage merge scenarios.
The lo_and_wo symbol tests #111341.
