From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=W2h5=3W=suse.de=rguenther@sourceware.org>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d])
	by sourceware.org (Postfix) with ESMTPS id 0065E3853D74
	for <gcc-patches@gcc.gnu.org>; Tue, 22 Nov 2022 10:58:56 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0065E3853D74
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 C9B4F1F86B;
	Tue, 22 Nov 2022 10:58:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1669114735; 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=HXREIZjE5rA89TX+tfKD3EcpWHLh7amD6XoDg3XvMKw=;
	b=yecIeVKEV9ha44nDF1Jzoy/x/oQAgegNe6F3aT7wVevS22ddGG2slAUE6dlciPGUubFh9i
	KFJFnDMUv32TTteYyHvCrC9mLMrc+9X/0MI2en292o+qPMEVYBXtcvw/RmEN6Gx4UdRsoo
	EhYxAnuY5dC19UKjnauebUOKfLQXby8=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1669114735;
	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=HXREIZjE5rA89TX+tfKD3EcpWHLh7amD6XoDg3XvMKw=;
	b=kWigeGXFWl/7jWbWHomt+9Vdc8zPJ1uNjyr7aowDrmUgVWJtF0fA4qynf80NbEoHV23zUx
	tg2G/Vc/I193/EDw==
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 C02E72C239;
	Tue, 22 Nov 2022 10:58:55 +0000 (UTC)
Date: Tue, 22 Nov 2022 10:58:55 +0000 (UTC)
From: Richard Biener <rguenther@suse.de>
To: Richard Sandiford <richard.sandiford@arm.com>
cc: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org>, 
    Tamar Christina <Tamar.Christina@arm.com>, 
    Richard Biener <richard.guenther@gmail.com>, nd <nd@arm.com>
Subject: Re: [PATCH 1/8]middle-end: Recognize scalar reductions from bitfields
 and array_refs
In-Reply-To: <mpttu2r9sxz.fsf@arm.com>
Message-ID: <nycvar.YFH.7.77.849.2211221057230.3995@jbgna.fhfr.qr>
References: <patch-16240-tamar@arm.com> <CAFiYyc3E+4T2wB6NVNPcW2g5VoMgBSu-aso9S2ew3LwUUqy+Cw@mail.gmail.com> <VI1PR08MB53259E3A06CC8F6080018B3DFF3C9@VI1PR08MB5325.eurprd08.prod.outlook.com> <nycvar.YFH.7.77.849.2211071002260.4294@jbgna.fhfr.qr>
 <VI1PR08MB5325DE188F22EC1611452483FF3C9@VI1PR08MB5325.eurprd08.prod.outlook.com> <nycvar.YFH.7.77.849.2211071110080.4294@jbgna.fhfr.qr> <VI1PR08MB5325A99EACA0F2FB71581AAEFF3C9@VI1PR08MB5325.eurprd08.prod.outlook.com> <mpttu2r9sxz.fsf@arm.com>
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: <gcc-patches.gcc.gnu.org>

On Tue, 22 Nov 2022, Richard Sandiford wrote:

> Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> >> So it's not easily possible the within current infrastructure.  But it does look
> >> like ARM might eventually benefit from something like STV on x86?
> >> 
> >
> > I'm not sure.  The problem with trying to do this in RTL is that you'd have to be
> > able to decide from two psuedos whether they come from extracts that are
> > sequential. When coming in from a hard register that's easy yes.  When coming in
> > from a load, or any other operation that produces psuedos that becomes harder.
> 
> Yeah.
> 
> Just in case anyone reading the above is tempted to implement STV for
> AArch64: I think it would set a bad precedent if we had a paste-&-adjust
> version of the x86 pass.  AFAIK, the target capabilities and constraints
> are mostly modelled correctly using existing mechanisms, so I don't
> think there's anything particularly target-specific about the process
> of forcing things to be on the general or SIMD/FP side.
> 
> So if we did have an STV-ish thing for AArch64, I think it should be
> a target-independent pass that uses hooks and recog, even if the pass
> is initially enabled for AArch64 only.

Agreed - maybe some of the x86 code can be leveraged, but of course
the cost modeling is the most difficult to get right - IIRC the x86
backend resorts to backend specific tuning flags rather than trying
to get rtx_cost or insn_cost "correct" here.

> (FWIW, on the patch itself, I tend to agree that this is really an
> SLP optimisation.  If the vectoriser fails to see the benefit, or if
> it fails to handle more complex cases, then it would be good to try
> to fix that.)

Also agreed - but costing is hard ;)

Richard.