From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id EBAA9385E02C for ; Fri, 4 Jun 2021 07:45:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EBAA9385E02C Received: by mail-pg1-x531.google.com with SMTP id r1so7193515pgk.8 for ; Fri, 04 Jun 2021 00:45:33 -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=1a62zEM7nrh9McClw6sOIji8ITnITEteJ5VGt0HL4dA=; b=qdSX8Z71UF4rj6pSh0hyIfP7L+8uiyJgymG/7zGLNsQbP2JVWkKKCFio3J7/lIGZh/ 6725ia707ePT4G6K5vUtnw+ThwDr8NiYBjpQhQNLaizh4uOve710UySdyG4QMKMQw7nU GrXkDBXqi6OGqvnmLjlqN7Dz2nYFwjW7m39fH3Hflqf3zNd8Pweii5iSSbJ5TdQUaE4t Qt5L4sVagVCkTKIzl/jqhnTSSRT7RO5LatQ4KTsg/AuHwAV9PkrWC0YdBd9/+pGUMV6Z 0kfgGS0i8jGoIGO4Y1LOFbAshh1QAw9fIVvzJ3WwTICvpDop1QC+OEX6+90OXyY4kB9P ohGw== X-Gm-Message-State: AOAM531CuI68s7psvpb8origT3muVhUemCc/WoKB4FQp5+XbqDNmODHR wMTLFcTXex1NZ1clzAzaI0Rk6kovXkOXDMGMtVA8ng== X-Google-Smtp-Source: ABdhPJyLYKK9sT6BrkOXUPuThHC2HfN6qWddYLAJtMEIYyZ76e2BOmre7sL+KWckyehyl2DPr9NpU3QoW+xQyWWqBeU= X-Received: by 2002:a62:90:0:b029:2db:90a5:74dc with SMTP id 138-20020a6200900000b02902db90a574dcmr3420919pfa.27.1622792732865; Fri, 04 Jun 2021 00:45:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christophe Lyon Date: Fri, 4 Jun 2021 09:45:22 +0200 Message-ID: Subject: Re: [ARM] PR98435: Missed optimization in expanding vector constructor To: Prathamesh Kulkarni Cc: gcc Patches , Kyrill Tkachov Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Fri, 04 Jun 2021 07:45:45 -0000 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. 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