From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id B89833858C62 for ; Thu, 13 Jul 2023 12:36:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B89833858C62 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-lj1-x236.google.com with SMTP id 38308e7fff4ca-2b743161832so9483641fa.1 for ; Thu, 13 Jul 2023 05:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689251797; x=1691843797; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=y4IypPUYeSXISGk9RbfoZZhS8lmfDP8G3H5mBre+FRU=; b=a5GrTucG0yI29jsSRHKNlclTET/E+8wlq+Ls9ff6XwHVU0BCPDij8MsPEmvOFniHGm ooSiC90xqbeXj0MlAZNOGzs1AYLrmbatZtrNOHA29/sE+BKAqsJpfVr/0mLMnoUg7oP7 98cWQ1Yv8zcs6CL4eVq9yvqMJykZ260eXfze8QSghqIApCw3k/ReX7kBT7h57McXt9sU 1e5EjGBT/KgjdzTLKrPj5aFKTkyOldzrp8Vmy9eh/K7tGPk7cPTxixKfgJU5RTfTvQrJ 1TkNUPvLv6O0W+ZOlrQSsGgAq2FNSrn17OBElrM8i6wnVDAH1AhliyBp23yP2qNs36hc Ef1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689251797; x=1691843797; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=y4IypPUYeSXISGk9RbfoZZhS8lmfDP8G3H5mBre+FRU=; b=ZAZQ0jDYDoImPT+xylspXvbIxZ2coo5cnVUfEA+Q74q899c5phSuHw2oyS7o3EEdsS 2bjEA+071WZzG96i68nHKpZXpOSHlkWwInANVrti+c5zrQihoIe5lDEEQx9lc3O7KgHE QNOHcUYgzXpRcqdqXm6xkFk0kPRNAe/+yGPN+jxGs5HLL3HPVHMIKIKmuaOaSETt/tIq Qh8vNKNVKlX6RoypYK9vVrmATbbpVDCwtFfHpAGs/ECNFc6Q7Iw7vvYvEN8kLO3mMvUM yuA0BImfjfguq9hkarxv6V3JcVMHsjKZ+7TqpkFL7WKOI5/72zTgKDfYiJ8aJIUyowRU vzSQ== X-Gm-Message-State: ABy/qLaUgfh+0WnbLWIykHVYDQQfXzA7X7nwgJErhE/YjoSlWsLIM9uI vJ1qNSCNjdYEE1YSwKOLDVAnK/2zLPyEe3ssze0= X-Google-Smtp-Source: APBJJlG/dcNWPem0NT4f88eFTPC1saSln8xRHip+ZLpCtGLSSQPKHRHZF7jmruMiKMTDpi5Z0UWc6NEjpckmN8Z4sUc= X-Received: by 2002:a2e:7e02:0:b0:2b5:8f85:bf67 with SMTP id z2-20020a2e7e02000000b002b58f85bf67mr1094949ljc.53.1689251797130; Thu, 13 Jul 2023 05:36:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 13 Jul 2023 14:36:12 +0200 Message-ID: Subject: Re: [PATCH] vect: Handle demoting FLOAT and promoting FIX_TRUNC. To: Robin Dapp Cc: gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 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,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 Thu, Jul 13, 2023 at 2:19=E2=80=AFPM Robin Dapp wr= ote: > > > Can you add testcases? Also the current restriction is because > > the variants you add are not always correct and I don't see any > > checks that the intermediate type doesn't lose significant bits? > > The testcases I wanted to add with a follow-up RISC-V patch but > I can also try an aarch64 one. > > So for my understanding, please correct, we have: > > promoting int -> float, should always be safe. We currently > vectorize this with WIDEN and NONE. > > demoting float -> int, this is safe as long as the float > value can be represented in the int type, otherwise we must > trap. > We currently vectorize this on x86 using NARROW (regardless > of -ftrapping-math) and using NONE only with -fno-trapping-math. > > demoting int -> float, this is safe as long as the > intermediate types can hold the initial value? How is > this different to demoting e.g. int64_t -> int8_t? > We currently do not vectorize this with either NARROW or NONE. > LLVM vectorizes but only with their default(?) -fno-trapping-math. > Yet I don't see how we could trap here? > > promoting float -> int, this is safe as long as the float > value can be represented (as above)? We currently vectorize > this (regardless of -ftrapping-math) with WIDEN but not NONE. > > So apart from unifying the -ftrapping-math behavior I think only > the third variant is somewhat critical? I think all demoting cases need checks that are not present right now irrespective of properly trapping. Richard. > Regards > Robin >