golang/go · error

Loong64 extension: invalid LSX/LASX arrangement type: {ext}

Error message

Loong64 extension: invalid LSX/LASX arrangement type: {ext}

What it means

Thrown by Loong64RegisterExtension when an LSX/LASX register is used in an index (element-access) context but the extension string `ext` is not a key in loong64ElemExtMap. The index-branch only accepts the eight element-type suffixes B, H, W, V, BU, HU, WU, VU; anything else (including a valid arrangement suffix like B16) is rejected here because index access encodes an element width, not a full vector arrangement.

Source

Thrown at src/cmd/asm/internal/arch/loong64.go:96

	var arngType int16
	var simdType int16
	var simdReg int16

	switch {
	case reg >= loong64.REG_V0 && reg <= loong64.REG_V31:
		simdType = loong64.LSX
		simdReg = reg - loong64.REG_V0
	case reg >= loong64.REG_X0 && reg <= loong64.REG_X31:
		simdType = loong64.LASX
		simdReg = reg - loong64.REG_X0
	default:
		return errors.New("Loong64 extension: invalid LSX/LASX register: " + fmt.Sprintf("%d", reg))
	}

	if isIndex {
		arngType, ok = loong64ElemExtMap[ext]
		if !ok {
			return errors.New("Loong64 extension: invalid LSX/LASX arrangement type: " + ext)
		}

		a.Reg = loong64.REG_ELEM
		a.Reg += ((simdReg & loong64.EXT_REG_MASK) << loong64.EXT_REG_SHIFT)
		a.Reg += ((arngType & loong64.EXT_TYPE_MASK) << loong64.EXT_TYPE_SHIFT)
		a.Reg += ((simdType & loong64.EXT_SIMDTYPE_MASK) << loong64.EXT_SIMDTYPE_SHIFT)
		a.Index = num
	} else {
		switch simdType {
		case loong64.LSX:
			arngType, ok = loong64LsxArngExtMap[ext]
			if !ok {
				return errors.New("Loong64 extension: invalid LSX arrangement type: " + ext)
			}

		case loong64.LASX:
			arngType, ok = loong64LasxArngExtMap[ext]
			if !ok {

View on GitHub (pinned to b6b368adc5)

Solutions

  1. Change the index suffix to one of the valid element types: B, H, W, V, BU, HU, WU, or VU.
  2. If you intended a full-vector arrangement rather than an element access, remove the index form (drop the `[N]` / isIndex usage) so the arrangement-branch (errors 61/62) applies instead.
  3. Double-check whether the register is V0-V31 (LSX) or X0-X31 (LASX); element suffixes are shared but arrangement suffixes differ per SIMD width.

Example fix

// before (invalid index suffix)
VADDI V0.B16[0], V1, V2
// after (valid element suffix for indexed access)
VADDI V0.B[0], V1, V2
Defensive patterns

Strategy: validation

Validate before calling

// Validate an LSX/LASX index element suffix before assembling.
var validElemExt = map[string]bool{"B":true,"H":true,"W":true,"V":true,"BU":true,"HU":true,"WU":true,"VU":true}
func validIndexExt(ext string) bool { return validElemExt[ext] }

Type guard

// n/a: Loong64 assembly suffixes are strings, validated by lookup.
func isValidLoong64ElemExt(ext string) bool {
    switch ext { case "B","H","W","V","BU","HU","WU","VU": return true }
    return false
}

Prevention

When it happens

Trigger: Calling Loong64RegisterExtension with isIndex==true and an `ext` value absent from loong64ElemExtMap. In hand-written or generated Loong64 assembly this maps to an indexed vector operand like `V0[B]` where the bracketed suffix is not one of B/H/W/V/BU/HU/WU/VU.

Common situations: Authoring Loong64 SIMD assembly (LSX/LASX) and using an arrangement suffix (e.g. B16, H8) instead of an element suffix on an indexed access; typos in the element-width specifier; porting ARM SVE/NEON or RISC-V V assembly syntax that uses different suffix names.

Related errors


AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/d1482393f3ea04f6. Report an issue: GitHub.