From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id D963A3858D32 for ; Mon, 13 Mar 2023 07:33:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D963A3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id A17E81FE07; Mon, 13 Mar 2023 07:33:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1678692783; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eBz4TMWIT8YbbaUjG5A1sew/n5K9a/76frs6xOc/qiY=; b=g8JbYgEcgjyR0rFsIG6/Rr6TaNeriM97I7iOAmfDIYzSFMKu92UNct2vTzKpQewGUDSuCP u9db4vKBzm2nsjLL3gzKZpGRqpU7/xFxJAS1z7gR2rxMo7t6JwokA3k8VxKbc2d0C6N+SY Yoqyg4lgAxtk+5HvwBnbjgQ3GEUifeY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1678692783; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eBz4TMWIT8YbbaUjG5A1sew/n5K9a/76frs6xOc/qiY=; b=SDqFWzlTLtNQJXB0ckcL1y+u7XkiqgZ6Cd/BxZJPZ+VQKP51RKHZLIRIhGC6rob2tIp9iT kWuoAPSSbGOP/aCQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id BDD2C2C141; Mon, 13 Mar 2023 07:33:01 +0000 (UTC) Date: Mon, 13 Mar 2023 07:33:01 +0000 (UTC) From: Richard Biener To: Richard Sandiford cc: Prathamesh Kulkarni , gcc Patches Subject: Re: [aarch64] Use dup and zip1 for interleaving elements in initializing vector In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On Fri, 10 Mar 2023, Richard Sandiford wrote: > Sorry for the slow reply. > > Prathamesh Kulkarni writes: > > Unfortunately it regresses code-gen for the following case: > > > > svint32_t f(int32x4_t x) > > { > > return svdupq_s32 (x[0], x[1], x[2], x[3]); > > } > > > > -O2 code-gen with trunk: > > f: > > dup z0.q, z0.q[0] > > ret > > > > -O2 code-gen with patch: > > f: > > dup s1, v0.s[1] > > mov v2.8b, v0.8b > > ins v1.s[1], v0.s[3] > > ins v2.s[1], v0.s[2] > > zip1 v0.4s, v2.4s, v1.4s > > dup z0.q, z0.q[0] > > ret > > > > IIUC, svdupq_impl::expand uses aarch64_expand_vector_init > > to initialize the "base 128-bit vector" and then use dupq to replicate it. > > > > Without patch, aarch64_expand_vector_init generates fallback code, and then > > combine optimizes a sequence of vec_merge/vec_select pairs into an assignment: > > > > (insn 7 3 8 2 (set (reg:SI 99) > > (vec_select:SI (reg/v:V4SI 97 [ x ]) > > (parallel [ > > (const_int 1 [0x1]) > > ]))) "bar.c":6:10 2592 {aarch64_get_lanev4si} > > (nil)) > > > > (insn 13 9 15 2 (set (reg:V4SI 102) > > (vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 99)) > > (reg/v:V4SI 97 [ x ]) > > (const_int 2 [0x2]))) "bar.c":6:10 1794 {aarch64_simd_vec_setv4si} > > (expr_list:REG_DEAD (reg:SI 99) > > (expr_list:REG_DEAD (reg/v:V4SI 97 [ x ]) > > (nil)))) > > > > into: > > Trying 7 -> 13: > > 7: r99:SI=vec_select(r97:V4SI,parallel) > > 13: r102:V4SI=vec_merge(vec_duplicate(r99:SI),r97:V4SI,0x2) > > REG_DEAD r99:SI > > REG_DEAD r97:V4SI > > Successfully matched this instruction: > > (set (reg:V4SI 102) > > (reg/v:V4SI 97 [ x ])) > > > > which eventually results into: > > (note 2 25 3 2 NOTE_INSN_DELETED) > > (note 3 2 7 2 NOTE_INSN_FUNCTION_BEG) > > (note 7 3 8 2 NOTE_INSN_DELETED) > > (note 8 7 9 2 NOTE_INSN_DELETED) > > (note 9 8 13 2 NOTE_INSN_DELETED) > > (note 13 9 15 2 NOTE_INSN_DELETED) > > (note 15 13 17 2 NOTE_INSN_DELETED) > > (note 17 15 18 2 NOTE_INSN_DELETED) > > (note 18 17 22 2 NOTE_INSN_DELETED) > > (insn 22 18 23 2 (parallel [ > > (set (reg/i:VNx4SI 32 v0) > > (vec_duplicate:VNx4SI (reg:V4SI 108))) > > (clobber (scratch:VNx16BI)) > > ]) "bar.c":7:1 5202 {aarch64_vec_duplicate_vqvnx4si_le} > > (expr_list:REG_DEAD (reg:V4SI 108) > > (nil))) > > (insn 23 22 0 2 (use (reg/i:VNx4SI 32 v0)) "bar.c":7:1 -1 > > (nil)) > > > > I was wondering if we should add the above special case, of assigning > > target = vec in aarch64_expand_vector_init, if initializer is { > > vec[0], vec[1], ... } ? > > I'm not sure it will be easy to detect that. Won't the inputs to > aarch64_expand_vector_init just be plain registers? It's not a > good idea in general to search for definitions of registers > during expansion. > > It would be nice to fix this by lowering svdupq into: > > (a) a constructor for a 128-bit vector > (b) a duplication of the 128-bit vector to fill an SVE vector > > But I'm not sure what the best way of doing (b) would be. > In RTL we can use vec_duplicate, but I don't think gimple > has an equivalent construct. Maybe Richi has some ideas. On GIMPLE it would be _1 = { a, ... }; // (a) _2 = { _1, ... }; // (b) but I'm not sure if (b), a VL CTOR of fixed len(?) sub-vectors is possible? But at least a CTOR of vectors is what we use to concat vectors. With the recent relaxing of VEC_PERM inputs it's also possible to express (b) with a VEC_PERM: _2 = VEC_PERM <_1, _1, { 0, 1, 2, 3, 0, 1, 2, 3, ... }> but again I'm not sure if that repeating 0, 1, 2, 3 is expressible for VL vectors (maybe we'd allow "wrapping" here, I'm not sure). Richard. > We're planning to implement the ACLE's Neon-SVE bridge: > https://github.com/ARM-software/acle/blob/main/main/acle.md#neon-sve-bridge > and so we'll need (b) to implement the svdup_neonq functions. > > Thanks, > Richard > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)