From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id BD7FD384F489 for ; Fri, 18 Nov 2022 11:57:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BD7FD384F489 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668772640; h=from:from:reply-to:subject:subject: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=vwbHs0UL8NpeDxQtddPM48sA9v93rAJ17aXgCNFVyUY=; b=Pk9KxGhwDmStamV8TeuVwHviv6zrY4oHQVWkVVstuM2oSKQ5/KIOy5Q63Th6x310ZEtKwW 3ZsHj2W+x10p4viHeTFfNqSN5r3PLINg0KuxvxpNI2w6cV8Yi/oqPgQ54SMuOzICjeoB12 IBnyvRxzclwmisyZ8q8bhbrNjBPOK3M= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-296-okfA9eoKPvyQipiVCrwwDw-1; Fri, 18 Nov 2022 06:57:16 -0500 X-MC-Unique: okfA9eoKPvyQipiVCrwwDw-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-391842a55d6so39224717b3.0 for ; Fri, 18 Nov 2022 03:57:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=vwbHs0UL8NpeDxQtddPM48sA9v93rAJ17aXgCNFVyUY=; b=uvP9h+weOCQiSB4g1mH3SdNlNBMz0BnYUxHTncgw2axvtabUZOnFB/SGs3ki5u68ZJ J9Lj0uycM9sLuHGmnn5TQCe2Wvq80K9Iq9azJ/JSuxPA8K1yaAa2qejauoj0Xcv1xUcD criyISbOQ4IlqkBAhfNSZnFx0yJx5Tq89tSkvIIbf4MyDhyU+GVnSbDDW7QkGPh4wicx 6S6HAn3XxtldSiU9yYm9Hy9zKUku8/cDdniSdjWkF1nizEaSHHsLFgCTgyU5qENSA+1j o7QotQIhdVX2hfV4FXAe94yWlR34SKf6C2ndps7WQyYeanGQN7sTY3RmtRye6bO2FhiI 9/sg== X-Gm-Message-State: ANoB5pk0RGR/6k4/cYdm82BV14wu6dykhcAoxiBITkN+dWkTkfmQdt+g ddq4hUrHP6Y/OtCePEkAHt8QPtIFGE7tRQt40FfVAf8ic2L7q+XfXDzucgbHQMqZ5VOmRiaRs79 0LiJAiq7s8uwa/awRe9SbIXqnZ+pCCX1ynQ== X-Received: by 2002:a25:ad9c:0:b0:6dc:ad4b:a23e with SMTP id z28-20020a25ad9c000000b006dcad4ba23emr6220956ybi.617.1668772636342; Fri, 18 Nov 2022 03:57:16 -0800 (PST) X-Google-Smtp-Source: AA0mqf4xdHcm7MnhzjAPkY0aZ+UDJxcJbIZ/5D++FLTr3rWDV6tSUvgcZ1sie+VKiz+duOL5bN1qOzQso64Sw1SBKXQ= X-Received: by 2002:a25:ad9c:0:b0:6dc:ad4b:a23e with SMTP id z28-20020a25ad9c000000b006dcad4ba23emr6220947ybi.617.1668772636136; Fri, 18 Nov 2022 03:57:16 -0800 (PST) MIME-Version: 1.0 References: <20221113200553.440728-1-aldyh@redhat.com> <6150f7fd-5a57-c138-f65e-8dc3bf13d11a@codesourcery.com> <4441fc8a-e9e1-6fdd-20d1-473d10122426@codesourcery.com> <80f2ee68-8ec9-b3d8-82ea-88a1f12421e7@redhat.com> In-Reply-To: <80f2ee68-8ec9-b3d8-82ea-88a1f12421e7@redhat.com> From: Aldy Hernandez Date: Fri, 18 Nov 2022 12:57:03 +0100 Message-ID: Subject: Re: [PATCH] [range-ops] Implement sqrt. To: Jakub Jelinek Cc: Richard Biener , Joseph Myers , GCC patches , Andrew MacLeod X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000003028fe05edbd6859" X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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: --0000000000003028fe05edbd6859 Content-Type: text/plain; charset="UTF-8" I wonder if instead of disabling ranger altogether, we could disable code changes (constant propagation, jump threading and simplify_using_ranges)? Or does that sound like too much hassle? It seems that some passes (instruction selection?) could benefit from global ranges being available even if no propagation was done. Just a thought. I don't have strong opinions here. Aldy On Fri, Nov 18, 2022, 12:20 Aldy Hernandez wrote: > > > On 11/18/22 11:44, Jakub Jelinek wrote: > > On Fri, Nov 18, 2022 at 11:37:42AM +0100, Aldy Hernandez wrote: > >>> Practically strictly > >>> preserving IEEE exceptions is only important for a very small > audience, and > >>> for that even INEXACT will matter (but we still have -ftrapping-math > >>> by default). > >>> For that audience likely all constant / range propagation is futile > and thus the > >>> easiest thing might be to simply cut that off completely? > >>> > >>> I'd say what ranger does is reasonable with -ftrapping-math given the > current > >>> practice of handling this option. There's no point in trying to > preserve the > >>> (by accident) "better" handling without ranger. Instead as Joseph > says somebody > >>> would need to sit down, split -ftrapping-math, adjust the default and > thorougly > >>> document things (also with -fnon-call-exceptions which magically makes > >>> IEEE flag raising operations possibly throw exceptions). As there's > currently > >>> no code motion barriers for FP code with respect to exception flag > inspection > >>> any dead code we preserve is likely going to be unhelpful. > >>> > >>> So for now simply amend the documentation as to what -ftrapping-math > >>> currently means with respect to range/constant propagation? > >> > >> So something like "Even in the presence of -ftrapping-math, VRP may fold > >> operations that may cause exceptions For example, an addition that is > >> guaranteed to produce a NAN, may be replaced with a NAN, thus eliding > the > >> addition. This may cause any exception that may have been generated by > the > >> addition to not appear in the final program." > >> > >> ?? > > > > If we just adjust user expectations for -ftrapping-math, shouldn't we > > introduce another option that will make sure we never optimize away > floating > > point operations which can trap (and probably just disable frange for > that > > mode)? > > That seems like a big hammer, but sure. We could change > frange::supports_p() to return false for flag_severely_limiting_option :). > > Aldy > --0000000000003028fe05edbd6859--