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.
cc1a2ea61e 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.
Clang [defaults to aligning `__int128_t` to 16 bytes], while LLVM
`datalayout` strings [default to aligning `i128` to 8 bytes]. Wasm is
currently using the defaults for both, so it's inconsistent. Fix this by
adding `-i128:128` to Wasm's `datalayout` string so that it aligns
`i128` to 16 bytes too.
This is similar to
[llvm/llvm-project@dbad963](dbad963a69)
for SPARC.
This fixesrust-lang/rust#133991; see that issue for further discussion.
[defaults to aligning `__int128_t` to 16 bytes]:
f8b4182f07/clang/lib/Basic/TargetInfo.cpp (L77)
[default to aligning `i128` to 8 bytes]:
https://llvm.org/docs/LangRef.html#langref-datalayout
To temporarily address exchange2 perf regression reported in #118556
I disabled the inlining by default, and put it under engineering
option `-flang-simplify-hlfir-sum`.
Adds a new mlir-opt test-only pass, -test-vulkan-runner-pipeline, which
runs a set of passes needed for mlir-vulkan-runner, and removes them
from the runner. The tests are changed to invoke mlir-opt with this flag
before invoking the runner. The passes moved are ones concerned with
lowering of the device code prior to serialization to SPIR-V. This is an
incremental step towards moving the entire pipeline to mlir-opt, to
align with other runners (see #73457).
so that docgen can find our definitions.
Also eliminate the enums. POSIX is careful to call these "symbolic constants"
rather than specifically whether they are preprocessor macro defines or not.
Enums are useful to expressing mutual exclusion when the enum values are in
distinct enums which can improve type safety. Our enum values weren't using
that pattern though; they were all in one big anonymous enum.
Link:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/pthread.h.htmlFixes: #88997
docgen relies on the convention that we have a file foo.cpp in
libc/src/\<header\>/. Because the above functions weren't in libc/src/strings/
but rather libc/src/string/, docgen could not find that we had implemented
these.
Rather than add special carve outs to docgen, let's fix up our sources for
these 7 functions to stick with the existing conventions the rest of the
codebase follows.
Link: #118860Fixes: #118875
Adds initial CMake cache definition that is similar to what we use in
one of our production buidlbots. The goal is to consolidate the
configurations and make them accessible.
This cache file is a first step and to prepare for full pipeline testing
once the new bot comes online.
