`has_target_feature`

fn def has_target_feature[name: __mlir_type.`!kgen.string`, //, feature: StringLiteral[name]]() -> Bool

Whether an LLVM target feature is enabled for this compilation.

Feature names are LLVM’s own, written without the leading + that --target-features uses — "sha2", not "+sha2".

This answers a different question than target_triple(): the triple says which architecture is being compiled for, this says which of that architecture’s optional extensions the compilation may actually emit. A hardware backend needs both, and gating on the triple alone is not enough — an intrinsic whose feature is off does not degrade gracefully, it fails the build outright (LLVM ERROR: Cannot select: intrinsic %llvm.x86.vsha512rnds2). Guarding with comptime if folds the branch away before the intrinsic is ever instantiated:

comptime if target_triple_contains_any(["x86_64"]) and has_target_feature[
    "sha512"
]():
    _compress_x86(state, block)
else:
    _compress_naive(state, block)

A feature LLVM does not recognise, or one belonging to a different architecture (asking for "sha512" on AArch64), is reported as disabled rather than raising — so a query is always safe to write, but a typo is silently False. Only a leading +/- is caught, as that is the one mistake the --target-features spelling invites.

Parameters:

name (__mlir_type.!kgen.string``): The feature name as a raw MLIR string, inferred from feature.
feature (StringLiteral[name]): The LLVM feature name to test, e.g. "sha2".

Returns:

Bool: True if feature is enabled for the current compilation target.

target_triple