From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 74B773858CDA for ; Tue, 27 Jun 2023 10:05:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 74B773858CDA 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 9F1751F459; Tue, 27 Jun 2023 10:05:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1687860312; 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=93pZNt+J4Ll3lDzM3pmH9uWhBJKIwE2IoXKYRYdAwSc=; b=leA16BIdZWuc8jQtGGWY5WQA64XkMsLw2gGMsb9kMPzyy2rACpKBkyvA2ilIlR9i02Rfah pc6LeaUtbH2OZZyhgCzwdN1oIBlVTwjqp/C/AT580dA8pU3JbPHCLYwNq/i65bQXiGfOCk N4yr9BMWsPjNTbE6VPh45mtw81UoRuc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1687860312; 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=93pZNt+J4Ll3lDzM3pmH9uWhBJKIwE2IoXKYRYdAwSc=; b=NaOpCMHYsNg6RtvtSkg0yEm/3C2DI1gli04OdKo+KzFlHxqw6zb5Qj8D7ytcaavaskS4Xt D41hTkQ8cLQDXQAQ== 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 7341A2C141; Tue, 27 Jun 2023 10:05:12 +0000 (UTC) Date: Tue, 27 Jun 2023 10:05:12 +0000 (UTC) From: Richard Biener To: Robin Dapp cc: gcc-patches , Tamar.Christina@arm.com Subject: Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE. In-Reply-To: <65b66423-d93d-c5f1-05da-7540a13a0bec@gmail.com> Message-ID: References: <3fc809a1-6667-daca-e95a-b0a58825e16f@gmail.com> <0ea59340-7946-51dc-a060-6f0fc1ccdda0@gmail.com> <802f50c6-6e1d-9e93-a75c-ce947bd1784b@gmail.com> <65b66423-d93d-c5f1-05da-7540a13a0bec@gmail.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=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Tue, 27 Jun 2023, Robin Dapp wrote: > > so I suggest to do a similar VECTOR_MODE_P check and your original test. > > So > > > > && (!VECTOR_MODE_P (TYPE_MODE (newtype)) > > || target_supports_op_p (newtype, op, optab_default)) > > > > OK with that change. > > Separate patch or into the original one? We needed element_mode because > TYPE_MODE wouldn't work for a vector_mode so it still somehow fits. You can put it into the original one. > Apart from that, out of curiosity, do we want the same optab mechanism > (try widening/widened op if the original one failed) for vector types as > well in the future? With the current design that would belong to vector lowering. So no, I don't think so. Richard.