From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by sourceware.org (Postfix) with ESMTPS id 01A503870854 for ; Wed, 3 Jun 2020 18:46:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 01A503870854 Received: by mail-wm1-x342.google.com with SMTP id v19so2911957wmj.0 for ; Wed, 03 Jun 2020 11:46:14 -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:content-transfer-encoding; bh=ELvWBPrM0Z9ekzjvz7SskJOvOEQUOwnMXeM/VirQPeo=; b=dWvgN2yvJebnqGMIKj89GfK97BwND0qBPPKMNY2hYHagjqC+v6Cq7LgGbFXNc6j7Y8 /3GTwjRB0H42ELmVFWUfDPTfT1oQkDXCHvngKQSEquuN3L2L2Pf3U1cOKZZZY1jcrX1E P/1xYu68YAbGJyvNv37UsPPewlI/Pqnc1j/iuCyTBo3Mvq8VZuc0A1KTo4ZgW3v60f24 xmeXrljt0j3jqcOU8RFI22ADtVVpHx4XIgtWBmSqkQhhcvT8iAZdi6iTg77daDRM9m2M JYUA/cWPQk1Cl6roFyLlcxW/avJKeuMPbjPQs1W9k7b7FR9AhnQ/n6m+jv21kFciAWrp QKCA== X-Gm-Message-State: AOAM532R1dV7zN/DqaLErCef7RZ7EekadRcvei15tYedsLaxHPnFSqee 7wqU5f6mvZ/0I2RqRouBbcxH+fVeoO2En3oPUsw= X-Google-Smtp-Source: ABdhPJzaC2rOJ47PgSYrZvXGGEXXlZ314Vh/moGrPlRKDFuoZuzbOEa8jI/618eX/HS0y1o/oD/G5jnAKC0OoIx8nJ8= X-Received: by 2002:a7b:c1d4:: with SMTP id a20mr433479wmj.153.1591209974073; Wed, 03 Jun 2020 11:46:14 -0700 (PDT) MIME-Version: 1.0 References: <20200530130801.GD31009@gate.crashing.org> <16e3957c-e390-5984-b14e-dd3c70c3bd1c@suse.cz> <20200603170139.GY31009@gate.crashing.org> <8D461F7D-3BFF-4ABD-9E10-176E8F695506@gmail.com> <20200603182314.GZ31009@gate.crashing.org> <77CDEEE9-8B55-4B7B-BB51-48047AD94B4C@gmail.com> In-Reply-To: <77CDEEE9-8B55-4B7B-BB51-48047AD94B4C@gmail.com> From: David Edelsohn Date: Wed, 3 Jun 2020 14:46:02 -0400 Message-ID: Subject: Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions. To: Richard Biener Cc: Segher Boessenkool , =?UTF-8?Q?Martin_Li=C5=A1ka?= , GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Wed, 03 Jun 2020 18:46:25 -0000 On Wed, Jun 3, 2020 at 2:38 PM Richard Biener wrote: > > On June 3, 2020 8:23:14 PM GMT+02:00, Segher Boessenkool wrote: > >On Wed, Jun 03, 2020 at 07:23:47PM +0200, Richard Biener wrote: > >> >> mask =3D vec_cmp of the comparison > >> >> true_masked =3D true_op & mask; > >> >> false_masked =3D false_op & ~mask; > >> >> result =3D true_masked | false_masked; > >> >> > >> >> but I believe this would be dead code never triggered. > >> > > >> >But that would be the generic code as well? Is that not useful to > >have > >> >in any case? > >> > >> Sure. If you remove the vcond patterns from your port the vectorizer > >will do this transparently for you. So if you do not actually have a > >more clever way of representing this in the ISA there's no point of the > >vcond patterns. (though I think the vec_cmp ones didn't originally > >exist) > > > >So why can the expander not just do that whenever the patterns FAIL as > >well? > > It could but all the vectorizer costing assumed it goes the 'cheaper' way= . So this is kind of a sanity check. And what when vec_cmp expansion fails = as well? Resort to scalar soft FP support as ultimate fallback? That sounds= very wrong as a auto vectorization result... > > >> The point is the vectorizer relies on a optab query for querying > >backend support and power claims vcond support here. If you then FAIL > >you have lied. (not in your interpretation of the pattern docs but in > >the implementations since introduction of vcond named patterns) > > > >Almost all RTL patterns are allowed to FAIL, and that is a very good > >thing. If the vectoriser does not allow that, *it* is buggy. > > Your opinion. Please suggest a better way to query target vector capabili= ties. > > >> So if you're happy I'll document explicitly that vector named > >patterns may not FAIL. > > > >That will not work in general at all, no. Please document it for only > >those RTL patterns you need it for (and it is documented per pattern > >currently, anyway). > > Sure, will do. But as Richard said, the documented list is the other way = around. > At least that was my interpretation. > > All vectorizer queried optabs have this constraint BTW. Looking at other primary targets, like x86, ARM, AArch64, I agree that other targets don't FAIL vector patterns in the same manner as scalar patterns. The design of Altivec support came with the work from RHES and no one at the time mentioned that FAILing those named patterns was incorrect. As Segher said, allowing named patterns to fail is fairly standard in GCC and the restriction for vector patterns seems to have appeared without warning or documentation. Maybe the vectorizer started to assume that (because of x86 behavior) but no one announced this. Again, I'm not saying that it is an incorrect design or policy, but that it seems to have been imposed retroactively. This needs to be documented. It needs to be applied uniformly throughout the common parts of the vectorizer and RTL generation. It needs to allow time for the Power port to adapt. And we need to test this thoroughly to catch unanticipated fallout. Thanks, David