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 95FA2385B515 for ; Mon, 23 Jan 2023 17:45:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 95FA2385B515 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=1674495952; 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=69eNqGmTmftWQIMngKHpwLNYY8RUxyz5PmZzaq4iM58=; b=MSFgYgSnncQQsmMvvqhzWH2/7Pn9sn6vi/399eZG/KarJ4BQtvfqkvC57kQ7YyWlu+QRaB BDkY+Uc1Q8gnqfNZc5Q2UWQ5s0JxWwKFW6alTpoYDCorLcVzpKFFPODzSt5U6XigsA38CC fEDp+yCDdxa/EPkeG9IQzxX0iypV9Eg= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-616-yQXi37ulM1WzfedOzvdK2Q-1; Mon, 23 Jan 2023 12:45:51 -0500 X-MC-Unique: yQXi37ulM1WzfedOzvdK2Q-1 Received: by mail-qt1-f199.google.com with SMTP id v15-20020ac873cf000000b003b6428b16deso4780870qtp.3 for ; Mon, 23 Jan 2023 09:45:51 -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:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=69eNqGmTmftWQIMngKHpwLNYY8RUxyz5PmZzaq4iM58=; b=qqmq0C+3quZFJUIzerMe6G9VB8kkTfafCPrtRDPWTletQlU9jKMgahHpvf3LgiHTZK B4y7gOLEpszcOI9/cPwkYnjV86cViHC0O97opa75EjWRfyb/Urj1/U15bqn+Ng/vifxK onayw56y0j5hNtDZ0QD1k4J1npWOwKAlyIALsh61VHiU2bnwmTIYE1tQVMtBCP0b/0VJ X6ySxGDD+Og4a8I3+qndzn/auf3KRtWAKn2vEtabdsJR5soDmtRm5U6NBWidSm+DXP2o Xx0DaeYOZCxUU78E97mcNU59CyBLdRWxIFInPvpD18+J9XgTooVZkXHuFgModD1k80GD sDMg== X-Gm-Message-State: AFqh2kp3w8O8TURBuioTpA7aMMqsOSFeBhMe0yGcwMMMi12za2FhJUGS uGyJNQA/EskIiObYZUna6PEGAB9+v7tDtmB5IpBBnRV2+lxfyUiV3MhwUfnTuyY2eeEV6TJRL1v uwI9GYoSfQ0T6Wj0mP8au9b0z54gw/AMfynP4oaiqQiP8/pgNXtzLvYPhALedgrDuIT1qRQ== X-Received: by 2002:ac8:498c:0:b0:3a8:3058:db43 with SMTP id f12-20020ac8498c000000b003a83058db43mr32596268qtq.57.1674495950224; Mon, 23 Jan 2023 09:45:50 -0800 (PST) X-Google-Smtp-Source: AMrXdXusK9hcUHx7xRmggVSUV2r6vk6CN3wmd0q+uhQcBROrpfZDi6y8uoHMAKaXMkFA/EznEPNmow== X-Received: by 2002:ac8:498c:0:b0:3a8:3058:db43 with SMTP id f12-20020ac8498c000000b003a83058db43mr32596244qtq.57.1674495949908; Mon, 23 Jan 2023 09:45:49 -0800 (PST) Received: from ?IPV6:2607:fea8:a263:f600::27bf? ([2607:fea8:a263:f600::27bf]) by smtp.gmail.com with ESMTPSA id bq35-20020a05620a46a300b0070209239b87sm12458586qkb.41.2023.01.23.09.45.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Jan 2023 09:45:49 -0800 (PST) Message-ID: <50dff5bb-6306-ad20-0d44-7ed308bba85d@redhat.com> Date: Mon, 23 Jan 2023 12:45:48 -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 2/2] tree-optimization/108447 - Add VREL_OTHER for FP unsupported relations. From: Andrew MacLeod To: gcc-patches Cc: "hernandez, aldy" , Jakub Jelinek , Richard Biener References: 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=-4.9 required=5.0 tests=BAYES_00,BODY_8BITS,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: Sorry should have mention the PR On 1/23/23 12:44, Andrew MacLeod wrote: > This patch adds VREL_OTHER to represent another relation we do not > understand.  It is used to represent the class fo relations arising > from floating point that are currently not represented. IN GCC 14 we > will determine exactly how to represent them, but for this release, > this should prevent us from getting things wrong at least. > > if intersection produces UNDEFINED and either of the relations feeding > it were <, <=, >, or >=   then it turns it to VR_OTHER.   the prevents > false sides of branches from combining to produce  UNDEFINED when they > end up being a known NAN. > > Union is adjusted such that < >, or <= >= also produce VREL_OTHER.   < > > cannot be properly represented, and <= >= was producing VARYING, > which is also not correct. > > Form the testcase: > >     : >     cmp1_10 = x_8(D) <= y_9(D); >     cmp2_11 = x_8(D) >= y_9(D); >     _3 = cmp1_10 & cmp2_11; >     if (_3 != 0) >       goto ; [INV] >     else >       goto ; [INV] > > Relational : (x_8(D) == y_9(D)) >     : >     // predicted unlikely by early return (on trees) predictor. >     goto ; [INV] > > >     : >     _4 = ~cmp1_10; >     _5 = ~cmp2_11; >     _1 = cmp1_10 | cmp2_11; >     _6 = ~_1; >     if (_1 != 0) >       goto ; [INV] >     else >       goto ; [INV] > > Relational : (x_8(D) unknown fp y_9(D)) >     : >     // predicted unlikely by early return (on trees) predictor. > > > The intersection "fix" is represented by the relation between x and y > in BB5.  Without the patch, ti would be UNDEFINED and we do not want > that. > > The union fix is what prevents us from folding the condition in bb_4.  > Without it, x<=y union x >=y comes out VARYING, when in fact I believe > it represents everything except a NAN. > > So with this fix, all the unrepresentative relations get lumped into > VREL_OTHER so we at least don't get it wrong.  For next release we can > take the time to figure out exactly how we want to proceed. > > This is currently in testing on x86_64-pc-linux-gnu, and assuming it > bootstraps with no regressions (a combined patch did before splitting > it in 2), OK for trunk?   OR does it need more tweaking? > > Andrew