From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 52BEC385841C for ; Tue, 27 Jun 2023 07:42:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 52BEC385841C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4fb77f21c63so2352049e87.2 for ; Tue, 27 Jun 2023 00:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687851726; x=1690443726; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KHsweJ5mwqbkaEuEHbpD0pY/s+qHKoVc9TuHppJ0MN4=; b=bno4P1hgTNMo0DIb8WSTKIrmeQM4PP+harFJem/lUFrF0gRyosXFg2bdLUXOM32fPt vI89y+gwmdiqp3ukMbwv4SqUtQ8ePijrg9s0P9lwY1mhUGREeWAOlKMt4LQrDAMjtgER hWvhPuJIATwOuRTsBJqA6ZYQWL89KvW08C/8aM6mmgaK1KlF2i6TcRWHvC5scS9Be6TC /H47tC9XLWY5he2D5SB0Nbbc8/WScvVGiEF6kQUkuPRfggJeGpMd0FuZcnvXxMei+uyp HYZjU0SVhEJtInpo0/CH1JLf72vcdKZF7kJadJCw+WP9chHa2JfA5hJBsAHSgPfV6Ijc k2Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687851726; x=1690443726; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KHsweJ5mwqbkaEuEHbpD0pY/s+qHKoVc9TuHppJ0MN4=; b=TVHk3sFuSSCl91ZqXivqfCq7KaK8mEx+dg0IdDgRO/6n1odhdxgyUg7PpvnSKDfGFf oqnjQrqxYw5oFQVYGUbycHDJ+7+FXBzsinTNJBAH5EJNjoI7I2359ZaAAiGnNhmbbL2j kE7mN/OhUH42z9H6Mh9/G4TFoZTdV4FRVLEhxpXic8PTGdDiAoutxyuXtqijObao4Iim sLHr8fyDnppR6RtZhNucrXEl2mDMf4aBVvcK2TwLwDoMUeZx1exTV61YoTsnk39ujPT9 FvByjI92ta9QkPcdSlE/Y4MSqFXkOo5W2u6JfGoDspMpb3d/KNP/5L9kpkspkSio+d2w eerA== X-Gm-Message-State: AC+VfDw6vzH9c4UqQMGHuZ3MoiJq4cplLkIAZhmzyAKc7YxFy+4d/Dwo 3x1a6ZdN40r1cpgT0ssA3y0= X-Google-Smtp-Source: ACHHUZ6b7hbwkZpOTvElF4Bv5/nSsXbuxRK+CbrzBp9qzvPINHshDhK7Ju3+4geFwBgUeefw6CIMLg== X-Received: by 2002:a05:6512:281f:b0:4fb:7665:9b0d with SMTP id cf31-20020a056512281f00b004fb76659b0dmr3543264lfb.12.1687851725385; Tue, 27 Jun 2023 00:42:05 -0700 (PDT) Received: from [192.168.1.23] (ip-046-005-130-086.um12.pools.vodafone-ip.de. [46.5.130.86]) by smtp.gmail.com with ESMTPSA id n2-20020a5d67c2000000b003127741d7desm9442794wrw.58.2023.06.27.00.42.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jun 2023 00:42:04 -0700 (PDT) Message-ID: <802f50c6-6e1d-9e93-a75c-ce947bd1784b@gmail.com> Date: Tue, 27 Jun 2023 09:42:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Cc: rdapp.gcc@gmail.com, gcc-patches , Tamar.Christina@arm.com Subject: Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE. Content-Language: en-US To: Richard Biener References: <3fc809a1-6667-daca-e95a-b0a58825e16f@gmail.com> <0ea59340-7946-51dc-a060-6f0fc1ccdda0@gmail.com> From: Robin Dapp In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: > 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? > 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)) ? Regards Robin