Inline assembly asserts when using wrong number of vector elements with physical register constraint

[arsenm]

This test case uses an <8 x i32> width physical register constraint, but tries to use it as a <9 x i32> typed value. This should just be an error, but it results in an assertion in SelectionDAGBuilder.

; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx900 < %s

define <9 x i32> @inline_asm_wrong_vector_type_assert_def() {
  %asm = call <9 x i32> asm sideeffect "; def $0", "={v[8:15]}"()
  ret <9 x i32> %asm
}

define void @inline_asm_wrong_vector_type_assert_use(<9 x i32> %val) {
  call void asm sideeffect "; use $0", "{v[8:15]}"(<9 x i32> %val)
  ret void
}

Hits this assertion:

Assertion failed: ((PartEVT.getVectorElementCount().getKnownMinValue() > ; ValueVT.getVectorElementCount().getKnownMinValue()) && (PartEVT.getVectorElementCount().isScalable() == ValueVT.getVectorElementCount().isScalable()) && "Cannot narrow, it would be a lossy transformation"), function getCopyFromPartsVector, file SelectionDAGBuilder.cpp, line 430.

Another similar failure happens if the result is a scalar:

define void @asm_assert_scalar_read_vector() {
  %asm = call i32 asm sideeffect "; def $0 ", "={s[4:5]}"()
  ret void
}

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

Author: Matt Arsenault (arsenm)

Details

This test case uses an <8 x i32> width physical register constraint, but tries to use it as a <9 x i32> typed value. This should just be an error, but it results in an assertion in SelectionDAGBuilder.

; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx900 < %s

define &lt;9 x i32&gt; @<!-- -->inline_asm_wrong_vector_type_assert_def() {
  %asm = call &lt;9 x i32&gt; asm sideeffect "; def $0", "={v[8:15]}"()
  ret &lt;9 x i32&gt; %asm
}

define void @<!-- -->inline_asm_wrong_vector_type_assert_use(&lt;9 x i32&gt; %val) {
  call void asm sideeffect "; use $0", "{v[8:15]}"(&lt;9 x i32&gt; %val)
  ret void
}

Hits this assertion:

Assertion failed: ((PartEVT.getVectorElementCount().getKnownMinValue() > ; ValueVT.getVectorElementCount().getKnownMinValue()) && (PartEVT.getVectorElementCount().isScalable() == ValueVT.getVectorElementCount().isScalable()) && "Cannot narrow, it would be a lossy transformation"), function getCopyFromPartsVector, file SelectionDAGBuilder.cpp, line 430.

[ritter-x2a]

@arsenm, do we want to enforce that the width of the register constraint exactly matches the IR type, or should some variants (e.g. that do not lose information through truncation) be allowed?
A comment in this test suggests that mismatched types are currently at least sometimes accepted.

Unless users rely on mismatched types, always erroring out when the constraints don't match seems reasonable to me.

As a point of reference: Constraints for x86's AVX(2) [xy]mm registers require strictly matching vector widths.

[arsenm]

For CPU targets, GCC is horrifyingly permissive with the constraints. I think we can be stricter to some degree, particular for vectors.

I think we need to tolerate mismatches between 16-bit types and 32-bit registers, since pre-gfx11 there are really only 16-bit operations on 32-bit registers. It does also seem generic inline assembly expects small illegal types (like i8) work with default promotion to i32.

For vectors it's less clear what the benefit to permissiveness would be. I think vectors should enforce strict matching.