Hexagon codegen with -fno-integrated-as (the external assembler path) fails to assemble HVX instructions, while the integrated assembler (ClangAs) handles them correctly.
The root cause is that clang does not forward the target features selected by -mhvx (and likely other target-feature flags) to the external assembler invocation. The integrated assembler receives target features directly from the compilation pipeline, but the external as invocation does not receive the equivalent features, so it rejects HVX opcodes it should otherwise support.
This points to a broader gap: the external assembler path is not guaranteed to be on par with the integrated assembler for Hexagon-specific target features. HVX is the concrete case found so far, but other target-feature-gated flags may have the same gap and should be audited.
This issue was recognized during discussions in #198902. It is a pre-existing issue, unrelated to the XQFloat/QFloat work in that PR it reproduces with any HVX-using code, not just QFloat.
Steps to reproduce
Compile any HVX-using source with -fno-integrated-as and -mhvx:
clang -target hexagon-unknown-elf -mhvx -mcpu=hexagonv79 -fno-integrated-as -c test.c
The external assembler step fails to assemble the emitted HVX instructions because the HVX target features selected by -mhvx are never made available to it.
Expected behavior
The target features selected by flags such as -mhvx (and other target-feature-gated Hexagon flags) should be propagated to the external assembler invocation when -fno-integrated-as is used, so that codegen behavior is consistent regardless of which assembler is selected.
Hexagon codegen with -fno-integrated-as (the external assembler path) fails to assemble HVX instructions, while the integrated assembler (ClangAs) handles them correctly.
The root cause is that clang does not forward the target features selected by -mhvx (and likely other target-feature flags) to the external assembler invocation. The integrated assembler receives target features directly from the compilation pipeline, but the external as invocation does not receive the equivalent features, so it rejects HVX opcodes it should otherwise support.
This points to a broader gap: the external assembler path is not guaranteed to be on par with the integrated assembler for Hexagon-specific target features. HVX is the concrete case found so far, but other target-feature-gated flags may have the same gap and should be audited.
This issue was recognized during discussions in #198902. It is a pre-existing issue, unrelated to the XQFloat/QFloat work in that PR it reproduces with any HVX-using code, not just QFloat.
Steps to reproduce
Compile any HVX-using source with -fno-integrated-as and -mhvx:
clang -target hexagon-unknown-elf -mhvx -mcpu=hexagonv79 -fno-integrated-as -c test.cThe external assembler step fails to assemble the emitted HVX instructions because the HVX target features selected by -mhvx are never made available to it.
Expected behavior
The target features selected by flags such as -mhvx (and other target-feature-gated Hexagon flags) should be propagated to the external assembler invocation when -fno-integrated-as is used, so that codegen behavior is consistent regardless of which assembler is selected.