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.129.124]) by sourceware.org (Postfix) with ESMTPS id 830203858C33 for ; Thu, 26 Jan 2023 14:24:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 830203858C33 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=1674743054; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WxCXRuy42FLgA6YhK6Ux+vORshPKVWXu6S95MX3fhWQ=; b=bCWnPX3hGTNI60dT7g2S4GY0B5xdN/Tg5yQ21MLmryOMsgvLU1HLQ3qtSURy1M1KtEDJlO ixgDp49EI8X4G+AZ+We4TiJjNgX0ud/VmABhhBtFUwQdS/z6EDXnVSA2AZW1QomDBwEtif ycYRLm5IUIygxhOgZF5hDGw3iDudoEQ= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-83-vLQ0oTUXOraPIlTh9IR_fQ-1; Thu, 26 Jan 2023 09:24:13 -0500 X-MC-Unique: vLQ0oTUXOraPIlTh9IR_fQ-1 Received: by mail-qk1-f200.google.com with SMTP id j10-20020a05620a288a00b0070630ecfd9bso1097406qkp.20 for ; Thu, 26 Jan 2023 06:24:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WxCXRuy42FLgA6YhK6Ux+vORshPKVWXu6S95MX3fhWQ=; b=SoXUZPOeNRLvPXdiz6Butz7OgOlZJShUnpva5RFs7wZvr2Nj3Obi1OTArO1LaWs9A9 a32Sr0oFl0lkvd1W9dnCcGtPJ5lKgf4sZus+L1wZjj0G1l/qAarpeDWR4I11TQVMslgw JWS1Y+/4DA2eS9NPiqkcfH91PpoyBDqoBEV8RSo4BUexklbKg2PCWLxGG61RHMR3tf5h 5xELjY7Y4DNz2aICaxvNVVDT5viI8kdrHAVu4x2j/DQWNZ9WAIupGjAFN6hVJB0Yxap+ uS/0UfN6/KB+vES74slGb0FC9EXemeQoS2rPTMrchFbqUatN+9h1aME1DuHIFfBFXkTM pA3Q== X-Gm-Message-State: AFqh2koLR0Qucj5iiJiHS5HIZCnlZgTa81EgUc6pLTix5FH+KHM1UYUo GJw5qH7DXScXJCMEMYYi1AudWOA+kvAVitmpyzg47fpsYEOByVIQftgMWqvMwQtret0+lPVXsAK +enxV8T58UB9sB18nCA== X-Received: by 2002:ac8:794d:0:b0:3a5:ad81:8aff with SMTP id r13-20020ac8794d000000b003a5ad818affmr48093368qtt.55.1674743052336; Thu, 26 Jan 2023 06:24:12 -0800 (PST) X-Google-Smtp-Source: AMrXdXsqaa2CeIBB1SJLCTgpRDJNO9HWxV0Lp9BetGUwGf+gszi0V2SKTc+0OT3YiCu5tC03qig29w== X-Received: by 2002:ac8:794d:0:b0:3a5:ad81:8aff with SMTP id r13-20020ac8794d000000b003a5ad818affmr48093345qtt.55.1674743052063; Thu, 26 Jan 2023 06:24:12 -0800 (PST) Received: from ?IPV6:2607:fea8:a263:f600::fa90? ([2607:fea8:a263:f600::fa90]) by smtp.gmail.com with ESMTPSA id y6-20020a05620a25c600b007023fc46b64sm708134qko.113.2023.01.26.06.24.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Jan 2023 06:24:11 -0800 (PST) Message-ID: Date: Thu, 26 Jan 2023 09:24:10 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH] PR tree-optimization/108447 - Do not try to logical fold floating point relations. To: Richard Biener Cc: gcc-patches , Jakub Jelinek , "hernandez, aldy" References: <0780922f-99b5-96fc-b921-9e00652f9741@redhat.com> From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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: On 1/26/23 02:13, Richard Biener wrote: > On Thu, Jan 26, 2023 at 8:09 AM Richard Biener > wrote: >> On Wed, Jan 25, 2023 at 7:05 PM Andrew MacLeod wrote: >>> This boils down to a single place where we are trying to do things with >>> relations in ranger that are simply not safe when we need to honor NANs. >>> >>> I think we can avoid all the other shuffling of relations, and simply >>> not perform this optimization when it comes to floats. >>> >>> The case the routine handles is: >>> >>> c_2 = a_6 > b_7 >>> c_3 = a_6 < b_7 >>> c_4 = c_2 && c_3 >>> >>> c_2 and c_3 can never be true at the same time, Therefore c_4 can always >>> resolve to false based purely on the relations. >>> >>> >>> Range-ops is unable to do this optimization directly as it requires >>> examining things from outside the statement, and is not easily >>> communicated a simple relation to operator_logical_and. >>> >>> This routine proceeds to look at the definitions of c_2 and c_3, tries >>> to determine if there are common operands, and queries for any relations >>> between them. If it turns out there is something, depending on whether >>> its && or || , we use intersection or union to determine if the result >>> of the logical operation can be folded. If HONOR_NANS is true for the >>> float type, then we cannot do this optimization, and bail early. >>> >>> At this point I do not think we need to do any of the other things >>> proposed to relations, so we don't need either of the other 2 patches >>> this release. >>> >>> Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk? >> + if (HONOR_NANS (TREE_TYPE (ssa1_dep1))) >> + return; >> >> would that rather be !(range-includes-nan (ssa1_dep1) || >> range-includes-nan (ssa1_dep2) || ..)? > Saw the discussion in the other thread only now, so OK. > >> That said, if the other 2 patches fix some latent issues in the new >> frange code I'd >> rather have them fixed. > So do we know bugs in the current code? You said some buggy > function isn't used, so better delete it. Are there other latent issues? > No bugs :-) At leats not related tot hat.    Yes, negate turns out to not currently be used (im sure it will eventually), but without the VREL_OTHER or other changes to relation representation, the negate table is currently correct. Andrew