From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 76EB83858D1E for ; Mon, 19 Sep 2022 13:42:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 76EB83858D1E 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-ej1-x62e.google.com with SMTP id go34so64566636ejc.2 for ; Mon, 19 Sep 2022 06:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=q3mntZ82tIdscmaamvm09nwLITiaLcLdC74rICdu2aM=; b=faVqKi9g71PA95QLyh4CLb/Q4FG5kUDK90P76289WrdGjiN9vGesrwbuD1bKcG7obO fzo8sqz/H9YqEzDGSLz6Yy2VmofiOcMMXOtLMPZ7fttb6byHNeUDR35fswCfODbVz729 ufg8uQHphALjvuGuKWetd4EhvC5zAZhZ43LZtuPq/hG2Oi4l2MG5BntFxdve8j+/4B35 b3BVVzwLNoyzKtNdLRuufF+plxb8djeOj2MwydUSe53GWMvvCkoSowfk2zpk2cDWJg5U E3QKxtRMQc4n0EcBM/VGSbyrycQZO7ZshYZ9OpLRaQ9kUs7wLGxP4xk4VSX7b5zpNgTp N/xQ== 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; bh=q3mntZ82tIdscmaamvm09nwLITiaLcLdC74rICdu2aM=; b=yyxZ3PTr+m77IYItPHc/SKueSTDcKzNk5EjdWHF6hgzhTclqvylLlOPsn9ffwzOAjk bbAaQv1sgm/heqTzslMfQCH/5YZSuInbBkN8ROo+hFBHB9BfVXhOHC4coF7TWfuGW7HM p2LWVdj0BXeuLruszIJYHRLoi72kPM/o2IjtlOTHTP2+7YVaFY2BE5LZl62EKQfZrlpe EncJQY4prQAPKWuiD/SKSEJYaWxgVLCzj3tvGG5oQAJjlKs1fOa/CHgTL0oZIHCL1GFy ogG2wyYNQZyPpvAmA79CTaUTeRQ2EAK0HUKjbnNeLJuSGlw5j4bbqLvEs2hgg6zLQ4PQ 8nGA== X-Gm-Message-State: ACrzQf2r6iWDLTr4NeNSw25s16wLiM9v04Zh1xJ/dvhy8VnV+q8zX/d3 RJKNkNMiKevi1jlPVsNsYSf3HnMGu6b2xshAYVg= X-Google-Smtp-Source: AMsMyM6C6JUIqVYkoRv0C/CtzeUymc/m3CPXtvzZjdhEnGWLPoDV8fgRzl/0Ocno4RRFX0x8cR+TVsIA0uFmAzt13Kk= X-Received: by 2002:a17:906:8251:b0:781:8016:2dc9 with SMTP id f17-20020a170906825100b0078180162dc9mr1431140ejx.488.1663594941119; Mon, 19 Sep 2022 06:42:21 -0700 (PDT) MIME-Version: 1.0 References: <20220919075901.1798294-1-aldyh@redhat.com> In-Reply-To: From: Richard Biener Date: Mon, 19 Sep 2022 15:42:09 +0200 Message-ID: Subject: Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN. To: Aldy Hernandez Cc: GCC patches , Jakub Jelinek , Andrew MacLeod Content-Type: text/plain; charset="UTF-8" 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 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 Mon, Sep 19, 2022 at 2:52 PM Aldy Hernandez wrote: > > On Mon, Sep 19, 2022 at 10:14 AM Richard Biener > wrote: > > > > On Mon, Sep 19, 2022 at 9:59 AM Aldy Hernandez wrote: > > > > > > ISTM that a specifically nonnegative range should not contain -NAN, > > > otherwise signbit_p() would return false, because we'd be unsure of the > > > sign. > > > > > > Do y'all agree? > > > > what tree_expr_nonnegative_p actually means isn't 100% clear. For REAL_CST > > it actually looks at the sign-bit but we have > > > > (simplify > > /* copysign(x,y) -> fabs(x) if y is nonnegative. */ > > (COPYSIGN_ALL @0 tree_expr_nonnegative_p@1) > > (abs @0)) > > > > is abs (@0) OK for sNaNs and -NaN/+NaN? > > At least for real_value's, ABS_EXPR works on NAN's. There's no > special code dealing with them. We just clear the sign bit: > > real_arithmetic: > case ABS_EXPR: > *r = *op0; > r->sign = 0; > break; > > > > > And we have > > > > /* Convert abs[u] (X) where X is nonnegative -> (X). */ > > (simplify > > (abs tree_expr_nonnegative_p@0) > > @0) > > > > where at least sNaN -> qNaN would be dropped? > > > > And of course > > > > (simplify > > /* signbit(x) -> 0 if x is nonnegative. */ > > (SIGNBIT tree_expr_nonnegative_p@0) > > { integer_zero_node; }) > > > > that is, is tree_expr_nonnegative_p actually tree_expr_sign or > > does tree_expr_nonnegative (x) mean x >= (typeof(X)) 0 > > or !(x < (typeof(X))0)? > > I have no idea, but I'm happy to have frange::set_nonnegative() do > whatever you agree on. > > Actually TBH, ranger only uses set_nonnegative for call's, not much else: > > if (range_of_builtin_call (r, call, src)) > ; > else if (gimple_stmt_nonnegative_warnv_p (call, &strict_overflow_p)) > r.set_nonnegative (type); > else if (gimple_call_nonnull_result_p (call) > || gimple_call_nonnull_arg (call)) > r.set_nonzero (type); > else > r.set_varying (type); > > but I guess it's good we do the right thing for correctness sake, and > if it ever gets used by someone else. > > > > > That said, 'set_nonnegative' could be interpreted to be without > > NaNs? > > Sounds good to me. How's this? Hmm, I merely had lots of questions above so I think to answer them we at least should document what 'set_nonnegative' implies in the abstract vrange class. It's probably safer to keep NaN in. For example unfolded copysign (x, 1.) will return true for x == -NaN but the result will be a NaN. Richard. > > Aldy