You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[OffloadBundler] Rework the ctor of OffloadTargetInfo to support AMDGPU's generic target (#122629)
The current parsing logic for the target string assumes it follows the
format `<kind>-<triple>-<target id>:<feature>`, such as
`hipv4-amdgcn-amd-amdhsa-gfx1030:+xnack`.
Specifically, it assumes that `<target id>` does not contain any `-`,
relying on `rsplit` for parsing.
However, this assumption breaks for AMDGPU's generic targets, which may
contain one or more `-`, such as `gfx10-3-generic` or `gfx12-generic`.
As a result, the existing approach using `rstrip` is no longer reliable.
This patch reworks the parsing logic to handle target strings more
robustly, including support for generic targets.
The bundler now strictly requires a 4-field target triple.
Additionally, a new Python helper function has been added to `config.py`
to normalize the target triple into the 4-field format when it is not,
ensuring tests pass reliably.
The bundler accepts target triples with or without the optional environment
270
-
field:
269
+
LLVM target triples can be with or without the optional environment field:
271
270
272
271
``<arch><sub>-<vendor>-<sys>``, or
273
272
``<arch><sub>-<vendor>-<sys>-<env>``
274
273
275
-
However, in order to standardize outputs for tools that consume bitcode
276
-
bundles, bundles written by the bundler internally use only the 4-field
277
-
target triple:
274
+
However, in order to standardize outputs for tools that consume bitcode bundles
275
+
and to parse target ID containing dashes, the bundler only accepts target
276
+
triples in the 4-field format:
278
277
279
278
``<arch><sub>-<vendor>-<sys>-<env>``
280
279
@@ -543,4 +542,4 @@ The compressed offload bundle begins with a header followed by the compressed bi
543
542
- **Compressed Data**:
544
543
The actual compressed binary data follows the header. Its size can be inferred from the total size of the file minus the header size.
545
544
546
-
> **Note**: Version 3 of the format is under development. It uses 64-bit fields for Total File Size and Uncompressed Binary Size to support files larger than 4GB. To experiment with version 3, set the environment variable `COMPRESSED_BUNDLE_FORMAT_VERSION=3`. This support is experimental and not recommended for production use.
545
+
> **Note**: Version 3 of the format is under development. It uses 64-bit fields for Total File Size and Uncompressed Binary Size to support files larger than 4GB. To experiment with version 3, set the environment variable `COMPRESSED_BUNDLE_FORMAT_VERSION=3`. This support is experimental and not recommended for production use.
0 commit comments