Extend Bazel rule implementation to enforce that all transitive
dependencies of libc_header_library targets (used to implement
hand-in-hand code sharing via headers) indeed only contain header files.
This fixes Bazel portion of PR #133126.
`delta_bytes % (32 ceilDiv elementBitwidth) != 0` condition is incorrect
in https://github.com/llvm/llvm-project/pull/135014
For example, last load is issued to load only one last element of fp16.
Then `delta bytes = 2`, `(32 ceildiv 16) = 2`. In this case it will be
judged as word aligned. It will send to fast path but get all zeros for
the fp16 because it cross the word boundary.
In reality the equation should be just `delta_bytes % 4` , since a word
is 4 bytes. This PR fix the bug by amending the mod target to 4.
The 1:N dialect conversion driver has been deprecated. Use the regular
dialect conversion driver instead. This commit deletes the 1:N dialect
conversion driver.
Note for LLVM integration: If you are already using the regular dialect conversion, but still have argument materializations in your code base, simply delete all `addArgumentMaterialization` calls.
For details, see
https://discourse.llvm.org/t/rfc-merging-1-1-and-1-n-dialect-conversions/82513.
libc_function_deps and deps are now identical, as we no longer need or
have special treatment for libc_function targets. Merge these attributes
passed to the libc_test macro, and fix all relevant libc_test macro
invocations. This change is a no-op.
This concludes cleanup started in
9b13d345303d819bb83de7ebbeb826d704add0bc.
Motivation: amdgpu buffer load instruction will return all zeros when
loading sub-word values. For example, assuming the buffer size is
exactly one word and we attempt to invoke
`llvm.amdgcn.raw.ptr.buffer.load.v2i32` starting from byte 2 of the
word, we will not receive the actual value of the buffer but all zeros
for the first word. This is because the boundary has been crossed for
the first word.
This PR come up with a fix to this problem, such that, it creates a
bounds check against the buffer load instruction. It will compare the
offset + vector size to see if the upper bound of the address will
exceed the buffer size. If it does, masked transfer read will be
optimized to `vector.load` + `arith.select`, else, it will continue to
fall back to default lowering of the masked vector load.
This macro is a no-op after 90c001ac9e1d92a1a95d191d1640ab5337a937e5:
libc_function macro now produce a "regular" cc_library target, without
modifying its name, and this target is intended to only be used in
tests.
Thus, libc_internal_target macro is no longer needed, and we can safely
treat libc_function rules and libc_support_library rules identically for
test purposes.
`libc_function_deps` attribute of a `libc_test` macro can also be
cleaned up, but I plan to do this in a subsequent change.
Instead of creating hundreds of implicit "filegroup" targets to keep
track of sources and textual headers required to build each libc
function or helper library, use Bazel aspects (see
https://bazel.build/versions/8.0.0/extending/aspects), which enable
transparent collection of transitive sources / textual headers while
walking the dependency DAG, and minimizes the Starlark overhead.
Co-authored-by: Jordan Rupprecht <rupprecht@google.com>
Replaces separate x86vector named intrinsic operations with direct calls
to LLVM intrinsic functions.
This rework reduces the number of named ops leaving only high-level MLIR
equivalents of whole intrinsic classes e.g., variants of AVX512 dot on
BF16 inputs. Dialect conversion applies LLVM intrinsic name mangling
further simplifying lowering logic.
The separate conversion step translating x86vector intrinsics into LLVM
IR is also eliminated. Instead, this step is now performed by the
existing llvm dialect infrastructure.
RFC:
https://discourse.llvm.org/t/rfc-simplify-x86-intrinsic-generation/85581
After 3801bf6164f570a145e3ebd20cf9114782ae0329, SPIRVAnalysis needs to
include SPIRV.h provided by SPIRVCodegen, but the CodeGen target already
depends on Analysis, so that would cause a circular dependency.
Analysis is a subdirectory of CodeGen so it makes sense as a part of the
main CodeGen target too.
Fix two instances of libcxx_shared_headers depending on .cpp files (in
Bazel build):
* Don't depend on exit syscall in LIBC_ASSERT implementation. This
dependency is not used, since LIBC_ASSERT always uses system <assert.h>
in the overlay mode, which is the only mode supported by Bazel.
* Don't depend on libc_errno in str-to-float and str-to-integer
conversions. We only need the ERANGE value, which can be obtained from
the proxy header instead.
MacOS platforms using mlir-runner in lit tests consistently hit the
following error:
```
# .---command stderr------------
# | JIT session error: Symbols not found: [ __mlir_ciface_printMemrefI32 ]
# | Error: Failed to materialize symbols: { (main, { __mlir_printMemrefI32, ... }) }
# `-----------------------------
```
https://github.com/google/heir/issues/1521#issuecomment-2751303404
confirms the issue is fixed by using `alwayslink` on these two targets,
and I confirmed on a separate Apple M1 (OSX version Sequoia 15.3.2.).
I'm not an expert on the mlir runner internals, but given the
mlir-runner is purely for testing, and alwayslink at worst adds some
overhead by not removing symbols, it seems low risk.
Create a proper way to build header-only libraries for llvm-libc code
sharing. Use it to group headers that can be shared with libcxx for
std::from_chars() implementation.
It mostly works, though the macro needs to be updated to enforce that no
.cpp files are listed in dependencies (it's not the case now) - see PR
#133126.
All downstream users are migrated, so we no longer need to produce
"public"/"release" cc_library target for each libc_function macro
invocation. Instead, we only create internal target (for testing), and
some filegroups, which will be picked up by the libc_release_library
invocation.
This allows us to get rid of "weak" argument to libc_function - this
decision is also postponed to libc_release_library configuration.
Fixes#130327.
