From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 8141F388E809 for ; Mon, 14 Jun 2021 08:02:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8141F388E809 Received: by mail-ej1-x630.google.com with SMTP id g8so15124543ejx.1 for ; Mon, 14 Jun 2021 01:02:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sa6bY6p1u/tAwzFwR15wpGJHWfi5hB9skhc3cvF7UT4=; b=Db150X5kNVWZ5UI/XP7so+I8dQ+KcSil5ApKVkv+rbBDWYiH2imoiBr++vUg17t5fC 8ewtdVv/rXsjfcPFhuCis1ZOk5BkavzjWJDTlU5phydC5ik/3vgBYzYkbx9jVTJDVRa2 FavdVwwjaz11Wb8LtkKWvuwlMqwiin6/j/Zw9OZL2Xvr5XU+76KkOoKNOLqB0QF7sdcT ek276R6y/a8hDI3DMC5Q1XAKWXQ9FHQ14IicAm9+eeeRAgnnpWW70W1WVp7P+wHEB8LT wv2VFu3L3S0XWjsXBXjT81JPJAS9Lh3vvPdoX7bQ2Q5tfjJcuY+HiEpl2e5u/qNN+tVf ueMQ== X-Gm-Message-State: AOAM533FfHKP8FsxfWdloHfTceuQ6xfGtYJ2knNkuvNdfSXblRDzQbw3 gRR6LVYBJjjrMp3wDrWQ/5hK4IbKLaiYwds2c1h6EA== X-Google-Smtp-Source: ABdhPJyLrAwBG2X0V4MufbVDFEO+WkZZJTkQO+ifeOCQyic9fzyNnzesPyuwPKkW5ARQxwR8gavhVvXsMR2ylm0SvOg= X-Received: by 2002:a17:906:ae91:: with SMTP id md17mr14812675ejb.433.1623657747515; Mon, 14 Jun 2021 01:02:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Prathamesh Kulkarni Date: Mon, 14 Jun 2021 13:31:50 +0530 Message-ID: Subject: Re: [ARM] PR98435: Missed optimization in expanding vector constructor To: Christophe Lyon Cc: gcc Patches , Kyrill Tkachov Content-Type: multipart/mixed; boundary="000000000000476ae405c4b547f5" X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 08:02:30 -0000 --000000000000476ae405c4b547f5 Content-Type: text/plain; charset="UTF-8" On Wed, 9 Jun 2021 at 15:58, Prathamesh Kulkarni wrote: > > On Fri, 4 Jun 2021 at 13:15, Christophe Lyon wrote: > > > > On Fri, 4 Jun 2021 at 09:27, Prathamesh Kulkarni via Gcc-patches > > wrote: > > > > > > Hi, > > > As mentioned in PR, for the following test-case: > > > > > > #include > > > > > > bfloat16x4_t f1 (bfloat16_t a) > > > { > > > return vdup_n_bf16 (a); > > > } > > > > > > bfloat16x4_t f2 (bfloat16_t a) > > > { > > > return (bfloat16x4_t) {a, a, a, a}; > > > } > > > > > > Compiling with arm-linux-gnueabi -O3 -mfpu=neon -mfloat-abi=softfp > > > -march=armv8.2-a+bf16+fp16 results in f2 not being vectorized: > > > > > > f1: > > > vdup.16 d16, r0 > > > vmov r0, r1, d16 @ v4bf > > > bx lr > > > > > > f2: > > > mov r3, r0 @ __bf16 > > > adr r1, .L4 > > > ldrd r0, [r1] > > > mov r2, r3 @ __bf16 > > > mov ip, r3 @ __bf16 > > > bfi r1, r2, #0, #16 > > > bfi r0, ip, #0, #16 > > > bfi r1, r3, #16, #16 > > > bfi r0, r2, #16, #16 > > > bx lr > > > > > > This seems to happen because vec_init pattern in neon.md has VDQ mode > > > iterator, which doesn't include V4BF. In attached patch, I changed > > > mode > > > to VDQX which seems to work for the test-case, and the compiler now generates: > > > > > > f2: > > > vdup.16 d16, r0 > > > vmov r0, r1, d16 @ v4bf > > > bx lr > > > > > > However, the pattern is also gated on TARGET_HAVE_MVE and I am not > > > sure if either VDQ or VDQX are correct modes for MVE since MVE has > > > only 128-bit vectors ? > > > > > > > I think patterns common to both Neon and MVE should be moved to > > vec-common.md, I don't know why such patterns were left in neon.md. > Since we end up calling neon_expand_vector_init for both NEON and MVE, > I am not sure if we should separate the pattern ? > Would it make sense to FAIL if the mode size isn't 16 bytes for MVE as > in attached patch so > it will call neon_expand_vector_init only for 128-bit vectors ? > Altho hard-coding 16 in the pattern doesn't seem a good idea to me either. ping https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572342.html (attaching patch as text). Thanks, Prathamesh > > Thanks, > Prathamesh > > > > That being said, I suggest you look at other similar patterns in > > vec-common.md, most of which are gated on > > ARM_HAVE__ARITH > > and possibly beware of issues with iwmmxt :-) > > > > Christophe > > > > > Thanks, > > > Prathamesh --000000000000476ae405c4b547f5 Content-Type: text/plain; charset="US-ASCII"; name="pr98435-2.txt" Content-Disposition: attachment; filename="pr98435-2.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kpwbvg6z0 ZGlmZiAtLWdpdCBhL2djYy9jb25maWcvYXJtL25lb24ubWQgYi9nY2MvY29uZmlnL2FybS9uZW9u Lm1kCmluZGV4IDZhNjU3MzMxN2NmLi4yN2RkNjcyY2E3NiAxMDA2NDQKLS0tIGEvZ2NjL2NvbmZp Zy9hcm0vbmVvbi5tZAorKysgYi9nY2MvY29uZmlnL2FybS9uZW9uLm1kCkBAIC00NTksMTAgKzQ1 OSwxMiBAQAogKQogCiAoZGVmaW5lX2V4cGFuZCAidmVjX2luaXQ8bW9kZT48Vl9lbGVtX2w+Igot ICBbKG1hdGNoX29wZXJhbmQ6VkRRIDAgInNfcmVnaXN0ZXJfb3BlcmFuZCIpCisgIFsobWF0Y2hf b3BlcmFuZDpWRFFYIDAgInNfcmVnaXN0ZXJfb3BlcmFuZCIpCiAgICAobWF0Y2hfb3BlcmFuZCAx ICIiICIiKV0KICAgIlRBUkdFVF9ORU9OIHx8IFRBUkdFVF9IQVZFX01WRSIKIHsKKyAgaWYgKFRB UkdFVF9IQVZFX01WRSAmJiBHRVRfTU9ERV9TSVpFIChHRVRfTU9ERSAob3BlcmFuZHNbMF0pKSAh PSAxNikKKyAgICBGQUlMOwogICBuZW9uX2V4cGFuZF92ZWN0b3JfaW5pdCAob3BlcmFuZHNbMF0s IG9wZXJhbmRzWzFdKTsKICAgRE9ORTsKIH0pCg== --000000000000476ae405c4b547f5--