From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 6C6253858D33 for ; Tue, 27 Jun 2023 08:46:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C6253858D33 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-out1.suse.de (Postfix) with ESMTP id 7CCDE2188F; Tue, 27 Jun 2023 08:46:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1687855618; 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=hgsoVLdLCNq5yum0d2MPmhXzkrGPc5Lf+izIdISlRI0=; b=NVuhdRKbXZlNdNwRR8pVbdUteKpw5BuHkhwc4Xh48hMjgm5jCmk6luB9oJq/u30wSQYFjx Og5KZypV0iP4CQjCpS+FX7+r6LEFeJ9Wj04DU6eNv428U+MqzKMv99U24G+deBr3wPAYu1 De1DKg0rTHjFUnXOpsXGjFrKlE9gBAw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1687855618; 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=hgsoVLdLCNq5yum0d2MPmhXzkrGPc5Lf+izIdISlRI0=; b=dfB8o9+zocONKOEkx7+PiREoJvbEIjEaW+y3DsfzW0C7rGS6P/m73D/a90AY4DvcTCOiuF jw/5iIIcv8hkpkBw== 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 68F752C141; Tue, 27 Jun 2023 08:46:58 +0000 (UTC) Date: Tue, 27 Jun 2023 08:46:58 +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: <802f50c6-6e1d-9e93-a75c-ce947bd1784b@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> 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: > > Why does the expander not have a fallback here? If we put up > > restrictions like this like we do for vector operations (after > > vector lowering!), we need to document this. Your check covers > > more than just FP16 types as well which I think is undesirable. > > I'm not sure I follow. What would we fall back to if > (_Float16)a + (_Float16)b is not supported? Should I provide > a (_Float16)((float)a + (float)b) fallback? But that would just > undo the simplification we performed. Or do you mean in optabs > already? Yeah, the optab should already have the fallback of WIDENing here? So why does that fail? > > So it seems for FP16 we need this for correctness (to not ICE) > > while for other modes it might be appropriate for performance > > (though I cannot imagine a target supporting say long double > > not supporting float). > > What about something like: > > - && target_supports_op_p (newtype, op, optab_default) > + && (!target_supports_op_p (itype, op, optab_default) > + || element_mode (newtype) != HFmode > + || target_supports_op_p (newtype, op, optab_default)) I'd say && (!target_supports_op_p (itype, op, optab_default) || target_supports_op_p (newtype, op, optab_default)) would make sense in general. But as said you'll likely find (many?) other places affected. Singling out HFmode probably doesn't work across targets since this mode isn't defined in generic code. Richard.