This involved a little bit of yak shaving because one of the new tests
depends on MPC, and we didn't have targets for it yet, so I ended up
needing to add a similar setup to what we have for MPFR.
Previously telemetry was optional at build-time in such a way that none
of it was built at all, but llvm/llvm-project@159b872b37 changed that
and now it's optional in a different way so we need to have it available
in the bazel BUILD graph.
The downstream build was having trouble transforming the previous list
comprehension, but it works on this one. I guess it just needs to look
like a proper target.
Add targets and tests for strfromf, strfromd and strfroml.
No idea why the standard committee decided that the long double function
should be "strfroml" instead of "strfromld" which would match "strtold"
and leave them space to add string from integer functions in future.
Adds targets for the stdbit functions. Since the names follow a strict
pattern, this is done via list comprehensions. I don't want to handwrite
all 50.
Details:
- Previously, we used the LLVM_BUILD_TELEMETRY flag to control whether
any Telemetry code will be built. This has proven to cause more nuisance
to both users of the Telemetry and any further extension of it. (Eg., we
needed to put #ifdef around caller/user code)
- So the new approach is to:
+ Remove this flag and introduce LLVM_ENABLE_TELEMETRY which would be
true by default.
+ If LLVM_ENABLE_TELEMETRY is set to FALSE (at buildtime), the library
would still be built BUT Telemetry cannot be enabled. And no data can be
collected.
The benefit of this is that it simplifies user (and extension) code
since we just need to put the check on Config::EnableTelemetry. Besides,
the Telemetry library itself is very small, hence the additional code to
be built would not cause any difference in build performance.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
TOSA MLIR profile-based validation is designed to identify the
profile/extension requirements for each operation in TOSA MLIR graph,
ensuring that TOSA operators conform to the profiles and extensions
enabled by the target implementation.
The available profiles/extensions are reflected in the availability
property attached to each TOSA operator in the dialect. The design of
availability, the profile/extension classes, and their interface, is
inspired by the SPIRV implementation.
This patch includes the following changes:
- Introduces profile and extension knowledge within the dialect and
establishes an interface to query this information.
- Implements profile-based validation logic in the pass.
- Adds a TargetEnv class that represents the capabilities enabled in the
target implementation, such as profiles, extensions, and levels.
- Adds a set of tests to ensure that profile and extension requirements
are properly attached to the operations and that validation correctly
verifies the requirements of a given operation against the target
implementation.
Move LinalgInterfaces.cpp from LinalgInterfaces to LinalgDialect target.
This allows TensorDialect to use header-only RelayoutOpInterface without introducing a hidden dependency on LinalgDialect (producing an `no-allow-shlib-undefined` error if a target depends on TensorDialect but not LinalgDialect).
Also reverts d64f177a2f because it's no longer needed.
The BUILD file changes in https://github.com/llvm/llvm-project/pull/127544 adds `LinalgInterfaces` which is incomplete without `LinalgDialect`.
For now, just add the `LinalgDialect` as dependency to tests which do not otherwise depend on it (but depend on `LinalgInterfaces` through e.g. `TensorDialect`).
This is a temporary solution until the dependency of `TensorDialect` is trimmed to just the `linalg::RelayoutOpInterface`, but not the other linalg interfaces. See https://github.com/llvm/llvm-project/pull/127544#pullrequestreview-2622065243.
