From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id A83823858C52 for ; Thu, 19 Jan 2023 12:08:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A83823858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-wr1-x430.google.com with SMTP id r30so1630249wrr.10 for ; Thu, 19 Jan 2023 04:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=DKggASDiw7L1HB4BJaZRL963a8Pz9FGhfYXFG9dBXzg=; b=wFM0ghLKc9sN4S+HEDOYAM41gZD+TwTwSPemGXzArBpVSWpFQJ2mwp4dvXMohivbXn ALPJT+EyDB+xxtTGdJav3oyFcAbntLjhTql8SZckjE4eTFQwXUNbohB6wFkHwYwtjE7a erTqOwbdLR4WDzY3oKu6wrMZC7WhbyzIMXe0IGB5HyOaouz2e/Y57gHwpCVmstrx+fUr RC+zHNgg/Dzqc0ZIJzu3sVDQmt64shEAHsCRaDRfRDvZK3w45s+obL9wbjXUeK3bGaLH /vg+ARsOGky+tZCGD31obCPK0Cuaay3jFm8IR/uAFeaQRzhhLK2j9z1AqOmq6l1IOzHE FEfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DKggASDiw7L1HB4BJaZRL963a8Pz9FGhfYXFG9dBXzg=; b=bME/dMlmENViLepLVLb4JE4UywGo+atIro9RxOxRwWmv2zrwUBBLgAvBPRRteUFuzy gglCsNP+WKSCtHohEyW6F7MsOJjyqmiO6okYeZxjMb6Eqr8MF9VPKut1okXG0CuQJfhS 7o0tjU0xQ4lZ9CRZYHSDHQbr+1Nc58AGNlWnyQXOz48rRx0Iru7P78IGn4B16ivc7YU2 +xFiou7qDQbljoMne73zExjKJMqpoDuNttniCjSY88B8D4G5mTJ0pv45Xo36y8Q7hG6i a3V2iHI5Lu3WMLLpawOkw5GUqxurxwrE58ngbnrqJRHmpqruRXgXbk94ywzjiNEOkTKC Kd1Q== X-Gm-Message-State: AFqh2kpp4clHxuhoKs6aZ43dSGZBS4xSIRBjB6C/AEohzUtiwUMPFLb0 6k9EzOi4u5snZ05ta5aYl1rskXUN0aUDKKQbb3kc8Q== X-Google-Smtp-Source: AMrXdXuFAup+DDvyAEEpxcLD3tK6trkPr5TFy7nPazrvhrobg55pA/qbAnWi0baBec3jx0bpFq0isbUToirgj5l/Ki8= X-Received: by 2002:adf:f701:0:b0:2bd:dbb1:7e52 with SMTP id r1-20020adff701000000b002bddbb17e52mr458302wrp.173.1674130114245; Thu, 19 Jan 2023 04:08:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Prathamesh Kulkarni Date: Thu, 19 Jan 2023 17:37:57 +0530 Message-ID: Subject: Re: [aarch64] Use wzr/xzr for assigning vector element to 0 To: Prathamesh Kulkarni , gcc Patches , richard.sandiford@arm.com Content-Type: multipart/mixed; boundary="000000000000c4c93305f29cca91" X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000c4c93305f29cca91 Content-Type: text/plain; charset="UTF-8" On Wed, 18 Jan 2023 at 19:59, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Tue, 17 Jan 2023 at 18:29, Richard Sandiford > > wrote: > >> > >> Prathamesh Kulkarni writes: > >> > Hi Richard, > >> > For the following (contrived) test: > >> > > >> > void foo(int32x4_t v) > >> > { > >> > v[3] = 0; > >> > return v; > >> > } > >> > > >> > -O2 code-gen: > >> > foo: > >> > fmov s1, wzr > >> > ins v0.s[3], v1.s[0] > >> > ret > >> > > >> > I suppose we can instead emit the following code-gen ? > >> > foo: > >> > ins v0.s[3], wzr > >> > ret > >> > > >> > combine produces: > >> > Failed to match this instruction: > >> > (set (reg:V4SI 95 [ v ]) > >> > (vec_merge:V4SI (const_vector:V4SI [ > >> > (const_int 0 [0]) repeated x4 > >> > ]) > >> > (reg:V4SI 97) > >> > (const_int 8 [0x8]))) > >> > > >> > So, I wrote the following pattern to match the above insn: > >> > (define_insn "aarch64_simd_vec_set_zero" > >> > [(set (match_operand:VALL_F16 0 "register_operand" "=w") > >> > (vec_merge:VALL_F16 > >> > (match_operand:VALL_F16 1 "const_dup0_operand" "w") > >> > (match_operand:VALL_F16 3 "register_operand" "0") > >> > (match_operand:SI 2 "immediate_operand" "i")))] > >> > "TARGET_SIMD" > >> > { > >> > int elt = ENDIAN_LANE_N (, exact_log2 (INTVAL (operands[2]))); > >> > operands[2] = GEN_INT ((HOST_WIDE_INT) 1 << elt); > >> > return "ins\\t%0.[%p2], wzr"; > >> > } > >> > ) > >> > > >> > which now matches the above insn produced by combine. > >> > However, in reload dump, it creates a new insn for assigning > >> > register to (const_vector (const_int 0)), > >> > which results in: > >> > (insn 19 8 13 2 (set (reg:V4SI 33 v1 [99]) > >> > (const_vector:V4SI [ > >> > (const_int 0 [0]) repeated x4 > >> > ])) "wzr-test.c":8:1 1269 {*aarch64_simd_movv4si} > >> > (nil)) > >> > (insn 13 19 14 2 (set (reg/i:V4SI 32 v0) > >> > (vec_merge:V4SI (reg:V4SI 33 v1 [99]) > >> > (reg:V4SI 32 v0 [97]) > >> > (const_int 8 [0x8]))) "wzr-test.c":8:1 1808 > >> > {aarch64_simd_vec_set_zerov4si} > >> > (nil)) > >> > > >> > and eventually the code-gen: > >> > foo: > >> > movi v1.4s, 0 > >> > ins v0.s[3], wzr > >> > ret > >> > > >> > To get rid of redundant assignment of 0 to v1, I tried to split the > >> > above pattern > >> > as in the attached patch. This works to emit code-gen: > >> > foo: > >> > ins v0.s[3], wzr > >> > ret > >> > > >> > However, I am not sure if this is the right approach. Could you suggest, > >> > if it'd be possible to get rid of UNSPEC_SETZERO in the patch ? > >> > >> The problem is with the "w" constraint on operand 1, which tells LRA > >> to force the zero into an FPR. It should work if you remove the > >> constraint. > > Ah indeed, sorry about that, changing the constrained works. > > "i" isn't right though, because that's for scalar integers. > There's no need for any constraint here -- the predicate does > all of the work. > > > Does the attached patch look OK after bootstrap+test ? > > Since we're in stage-4, shall it be OK to commit now, or queue it for stage-1 ? > > It needs tests as well. :-) > > Also: > > > Thanks, > > Prathamesh > > > > > >> > >> Also, I think you'll need to use zr for the zero, so that > >> it uses xzr for 64-bit elements. > >> > >> I think this and the existing patterns ought to test > >> exact_log2 (INTVAL (operands[2])) >= 0 in the insn condition, > >> since there's no guarantee that RTL optimisations won't form > >> vec_merges that have other masks. > >> > >> Thanks, > >> Richard > > > > [aarch64] Use wzr/xzr for assigning 0 to vector element. > > > > gcc/ChangeLog: > > * config/aaarch64/aarch64-simd.md (aarch64_simd_vec_set_zero): > > New pattern. > > * config/aarch64/predicates.md (const_dup0_operand): New. > > > > diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md > > index 104088f67d2..8e54ee4e886 100644 > > --- a/gcc/config/aarch64/aarch64-simd.md > > +++ b/gcc/config/aarch64/aarch64-simd.md > > @@ -1083,6 +1083,20 @@ > > [(set_attr "type" "neon_ins, neon_from_gp, neon_load1_one_lane")] > > ) > > > > +(define_insn "aarch64_simd_vec_set_zero" > > + [(set (match_operand:VALL_F16 0 "register_operand" "=w") > > + (vec_merge:VALL_F16 > > + (match_operand:VALL_F16 1 "const_dup0_operand" "i") > > + (match_operand:VALL_F16 3 "register_operand" "0") > > + (match_operand:SI 2 "immediate_operand" "i")))] > > + "TARGET_SIMD && exact_log2 (INTVAL (operands[2])) >= 0" > > + { > > + int elt = ENDIAN_LANE_N (, exact_log2 (INTVAL (operands[2]))); > > + operands[2] = GEN_INT ((HOST_WIDE_INT) 1 << elt); > > + return "ins\\t%0.[%p2], zr"; > > + } > > +) > > + > > (define_insn "@aarch64_simd_vec_copy_lane" > > [(set (match_operand:VALL_F16 0 "register_operand" "=w") > > (vec_merge:VALL_F16 > > diff --git a/gcc/config/aarch64/predicates.md b/gcc/config/aarch64/predicates.md > > index ff7f73d3f30..901fa1bd7f9 100644 > > --- a/gcc/config/aarch64/predicates.md > > +++ b/gcc/config/aarch64/predicates.md > > @@ -49,6 +49,13 @@ > > return CONST_INT_P (op) && IN_RANGE (INTVAL (op), 1, 3); > > }) > > > > +(define_predicate "const_dup0_operand" > > + (match_code "const_vector") > > +{ > > + op = unwrap_const_vec_duplicate (op); > > + return CONST_INT_P (op) && rtx_equal_p (op, const0_rtx); > > +}) > > + > > We already have aarch64_simd_imm_zero for this. aarch64_simd_imm_zero > is actually more general, because it works for floating-point modes too. > > I think the tests should cover all modes included in VALL_F16, since > that should have picked up this and the xzr thing. Hi Richard, Thanks for the suggestions. Does the attached patch look OK ? I am not sure how to test for v4bf and v8bf since it seems the compiler refuses conversions to/from bfloat16_t ? Thanks, Prathamesh > > Thanks, > Richard > > > (define_predicate "subreg_lowpart_operator" > > (ior (match_code "truncate") > > (and (match_code "subreg") --000000000000c4c93305f29cca91 Content-Type: text/plain; charset="US-ASCII"; name="gnu-811-6.txt" Content-Disposition: attachment; filename="gnu-811-6.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ld3129yb0 W2FhcmNoNjRdIFVzZSB3enIveHpyIGZvciBhc3NpZ25pbmcgMCB0byB2ZWN0b3IgZWxlbWVudC4K CmdjYy9DaGFuZ2VMb2c6CgkqIGNvbmZpZy9hYWFyY2g2NC9hYXJjaDY0LXNpbWQubWQgKGFhcmNo NjRfc2ltZF92ZWNfc2V0X3plcm88bW9kZT4pOgoJTmV3IHBhdHRlcm4uCgpnY2MvdGVzdHN1aXRl L0NoYW5nZUxvZzoKCSogZ2NjLnRhcmdldC9hYXJjaDY0L3ZlYy1zZXQtemVyby5jOiBOZXcgdGVz dC4KCmRpZmYgLS1naXQgYS9nY2MvY29uZmlnL2FhcmNoNjQvYWFyY2g2NC1zaW1kLm1kIGIvZ2Nj L2NvbmZpZy9hYXJjaDY0L2FhcmNoNjQtc2ltZC5tZAppbmRleCA3ZjIxMmJmMzdjZC4uNzQyOGU3 NGJlYWYgMTAwNjQ0Ci0tLSBhL2djYy9jb25maWcvYWFyY2g2NC9hYXJjaDY0LXNpbWQubWQKKysr IGIvZ2NjL2NvbmZpZy9hYXJjaDY0L2FhcmNoNjQtc2ltZC5tZApAQCAtMTA4Myw2ICsxMDgzLDIw IEBACiAgIFsoc2V0X2F0dHIgInR5cGUiICJuZW9uX2luczxxPiwgbmVvbl9mcm9tX2dwPHE+LCBu ZW9uX2xvYWQxX29uZV9sYW5lPHE+IildCiApCiAKKyhkZWZpbmVfaW5zbiAiYWFyY2g2NF9zaW1k X3ZlY19zZXRfemVybzxtb2RlPiIKKyAgWyhzZXQgKG1hdGNoX29wZXJhbmQ6VkFMTF9GMTYgMCAi cmVnaXN0ZXJfb3BlcmFuZCIgIj13IikKKwkodmVjX21lcmdlOlZBTExfRjE2CisJICAgIChtYXRj aF9vcGVyYW5kOlZBTExfRjE2IDEgImFhcmNoNjRfc2ltZF9pbW1femVybyIgIiIpCisJICAgICht YXRjaF9vcGVyYW5kOlZBTExfRjE2IDMgInJlZ2lzdGVyX29wZXJhbmQiICIwIikKKwkgICAgKG1h dGNoX29wZXJhbmQ6U0kgMiAiaW1tZWRpYXRlX29wZXJhbmQiICJpIikpKV0KKyAgIlRBUkdFVF9T SU1EICYmIGV4YWN0X2xvZzIgKElOVFZBTCAob3BlcmFuZHNbMl0pKSA+PSAwIgorICB7CisgICAg aW50IGVsdCA9IEVORElBTl9MQU5FX04gKDxudW5pdHM+LCBleGFjdF9sb2cyIChJTlRWQUwgKG9w ZXJhbmRzWzJdKSkpOworICAgIG9wZXJhbmRzWzJdID0gR0VOX0lOVCAoKEhPU1RfV0lERV9JTlQp IDEgPDwgZWx0KTsKKyAgICByZXR1cm4gImluc1xcdCUwLjxWZXR5cGU+WyVwMl0sIDx2d2NvcmU+ enIiOworICB9CispCisKIChkZWZpbmVfaW5zbiAiQGFhcmNoNjRfc2ltZF92ZWNfY29weV9sYW5l PG1vZGU+IgogICBbKHNldCAobWF0Y2hfb3BlcmFuZDpWQUxMX0YxNiAwICJyZWdpc3Rlcl9vcGVy YW5kIiAiPXciKQogCSh2ZWNfbWVyZ2U6VkFMTF9GMTYKZGlmZiAtLWdpdCBhL2djYy90ZXN0c3Vp dGUvZ2NjLnRhcmdldC9hYXJjaDY0L3ZlYy1zZXQtemVyby5jIGIvZ2NjL3Rlc3RzdWl0ZS9nY2Mu dGFyZ2V0L2FhcmNoNjQvdmVjLXNldC16ZXJvLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXgg MDAwMDAwMDAwMDAuLmMyNjBjYzllNDQ1Ci0tLSAvZGV2L251bGwKKysrIGIvZ2NjL3Rlc3RzdWl0 ZS9nY2MudGFyZ2V0L2FhcmNoNjQvdmVjLXNldC16ZXJvLmMKQEAgLTAsMCArMSwzMiBAQAorLyog eyBkZy1kbyBjb21waWxlIH0gKi8KKy8qIHsgZGctb3B0aW9ucyAiLU8yIiB9ICovCisKKyNpbmNs dWRlICJhcm1fbmVvbi5oIgorCisjZGVmaW5lIEZPTyh0eXBlKSBcCit0eXBlIGZfIyN0eXBlKHR5 cGUgdikgXAoreyBcCisgIHZbMV0gPSAwOyBcCisgIHJldHVybiB2OyBcCit9CisKK0ZPTyhpbnQ4 eDhfdCkKK0ZPTyhpbnQxNng0X3QpCitGT08oaW50MzJ4Ml90KQorCitGT08oaW50OHgxNl90KQor Rk9PKGludDE2eDhfdCkKK0ZPTyhpbnQzMng0X3QpCitGT08oaW50NjR4Ml90KQorCitGT08oZmxv YXQxNng0X3QpCitGT08oZmxvYXQzMngyX3QpCisKK0ZPTyhmbG9hdDE2eDhfdCkKK0ZPTyhmbG9h dDMyeDRfdCkKK0ZPTyhmbG9hdDY0eDJfdCkKKworLyogeyBkZy1maW5hbCB7IHNjYW4tYXNzZW1i bGVyLXRpbWVzICJpbnNcXHR2XFswLTlcXStcLmJcXFxbXFsxXF1cXFxdLCB3enIiIDIgfSB9ICov CisvKiB7IGRnLWZpbmFsIHsgc2Nhbi1hc3NlbWJsZXItdGltZXMgImluc1xcdHZcWzAtOVxdK1wu aFxcXFtcWzFcXVxcXF0sIHd6ciIgNCB9IH0gKi8KKy8qIHsgZGctZmluYWwgeyBzY2FuLWFzc2Vt Ymxlci10aW1lcyAiaW5zXFx0dlxbMC05XF0rXC5zXFxcW1xbMVxdXFxcXSwgd3pyIiA0IH0gfSAq LworLyogeyBkZy1maW5hbCB7IHNjYW4tYXNzZW1ibGVyLXRpbWVzICJpbnNcXHR2XFswLTlcXStc LmRcXFxbXFsxXF1cXFxdLCB4enIiIDIgfSB9ICovCg== --000000000000c4c93305f29cca91--