From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id A2AA5385AC2D for ; Fri, 28 Oct 2022 14:14:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A2AA5385AC2D 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-ed1-x52b.google.com with SMTP id i21so8052125edj.10 for ; Fri, 28 Oct 2022 07:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=gphN3kLyyS2Bq/9PAKLHlORmZUTrY/+0eRLBbCoKhNo=; b=fgepQXuFPDLL5FxXBVYNopsnwHiySw0VV3TMZ/+KRiN1OpofRdq86hm6oCqOebbuSL dgkyHcYAAmjgGyqpH0Fd/DXr1RPFtBo/gr6HpX7RX8Ef3GMI3PpzjbNt7BZkRww99RXK Q/2CFrludmZPtvTH/Qk+xVJL9i2xKhpJzDtMbuVOFKjvu7n2I7H5FC0RbIqUE56t2Ftd tVqhMceLCPOcCq5KYbiM1cwAYwY5xtVr6p+c+satV7VOUn8EYq05Dtrgq5o+IIVIRW45 WFrjC5d2yyV4VVlUl3Zfv+Vi0LWX8k4GAvejgwY+PA47ggITOBP1k1IvcG0O7yYq7+Mo 02ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gphN3kLyyS2Bq/9PAKLHlORmZUTrY/+0eRLBbCoKhNo=; b=tLw80sImu/dhPSzH1kLu6mqAuCa0sXVIdtkcichsJc4KDVAkF2jRNcXUB9H0xWfDGd 5RtvI13Mkr6yrRjZJ5+b+3PAtbQXQVGJcvee6hjHepPvTIuScZBjaC8p5GhAwXg1Gt4W evkK2/OYRkktXkm9P0kmHeonM9MBgYnzwHksSAoNlFY0DRLZNqEH4dgE5MdCI5KclBhI KrwuQG+KpJy9K6n8KBhHHtZ2NpT+43Jt5DnBVRDFaZit9RnohHZsYeLuV25wPWE70MFY hiOlh9T7EeNr3iEaC5A1eRqEM9Y+vutypplhcR7FgOpPbr+02sZzeDPgurFA0kBBize6 WXbg== X-Gm-Message-State: ACrzQf3Ff2TKgJwAMORi5ueh68sCmmtFQSbrXIBWy98Lm319VnDzteU7 hTl4V1kUhk65NtrLu6jusqM= X-Google-Smtp-Source: AMsMyM5SOpcjjoX16V8sv4O3aj34z/vhJDeIRyOZhtVAEIMxSDguBxyNnqLx1DrLx3KF+7/CHM8/Ww== X-Received: by 2002:a05:6402:1e96:b0:462:89aa:d402 with SMTP id f22-20020a0564021e9600b0046289aad402mr9433600edf.190.1666966471289; Fri, 28 Oct 2022 07:14:31 -0700 (PDT) Received: from smtpclient.apple (dynamic-077-002-094-095.77.2.pool.telefonica.de. [77.2.94.95]) by smtp.gmail.com with ESMTPSA id 9-20020a170906200900b0078a543e9301sm2176751ejo.200.2022.10.28.07.14.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 07:14:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: RFC - VRP1 default mode Date: Fri, 28 Oct 2022 16:14:19 +0200 Message-Id: <6C3EA0FC-6B7B-4E8D-8044-CF44407BB56C@gmail.com> References: <9588af4d-7c77-fad3-b845-9880139e28b1@redhat.com> Cc: Eric Botcazou , gcc-patches , "hernandez, aldy" , Jakub Jelinek , Jeff Law In-Reply-To: <9588af4d-7c77-fad3-b845-9880139e28b1@redhat.com> To: Andrew MacLeod X-Mailer: iPhone Mail (20B82) X-Spam-Status: No, score=-3.0 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: > Am 28.10.2022 um 15:59 schrieb Andrew MacLeod : >=20 > =EF=BB=BF >> On 10/28/22 09:46, Richard Biener wrote: >>> On Fri, Oct 28, 2022 at 3:43 PM Andrew MacLeod wro= te: >>>=20 >>> On 10/28/22 03:17, Richard Biener wrote: >>>> On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod wr= ote: >>>>> Figured I would ask what you guys think of making ranger the default f= or >>>>> the VRP1 pass now. >>>>>=20 >>>>> With partial equivalences and the other bits I checked in the past few= >>>>> weeks I'm not aware of much that the legacy VRP pass gets that ranger >>>>> doesn't. The only exception to that which I am aware of is the trick >>>>> played with the unreachable edges to set global ranges, but that is do= ne >>>>> in the DOM passes now anyway... so it just happens slightly later in t= he >>>>> optimization cycle. >>>> Note DOM should go away at some point. Why can this not happen during >>>> ranger driven VRP? >>> I have been working on that for the last 2 days. Turns out VRP1 can >>> remove builtin_unreachable from the >>> if (X) >>> __builtin_unreachable () >>>=20 >>> idiom and set the appropriate global ranges, but it has to leave those >>> with 2 ssa-names: >>>=20 >>> if (a_1 !=3D b_2) >>> __builtin_unreachable() >>>=20 >>> until the second pass of VRP or we lose the relationship between a_1 and= >>> b_2. That triggers some failures. Specifically a vectorizor fail >>> because it cant be sure that the start and end point are not the same >>> without the condition in the IL. Trying to store global relations over >>> multiple passes would be problematic at this stage of development, so I >>> don't see a problem with leaving it that way. >> Hmm, I don't remember VRP1 doing anything special with the above though? >> Did it somehow propagate the (un!)conditional equivalence? >=20 > So as I looked at builtin_unreachable(), it was very adhoc. That one of t= he roots of that artificial testcase in the PR I opened. Cascading calls wer= e not being handled in a consistent way. VRP1 removed some, dom removed some= .. they just kind of disappeared at some point, but not consistently. The P= R that Uli opened that Aldy fixed, I could make fail again with minor adjust= ments to the conditions. So I worked on a consistent approach. >=20 > My guess is the old range stored globally for that case for a_1 was probab= ly ~[b_2, b_2] meaning it was carried in the range. Until we have an overal= l global relation tracker, we can't represent that across passes. The global ranges were never symbolic, this was at most used during VRP itse= lf. >=20 > It appears that leaving those until VRP2 works fine... testsuite currentl= y running tho ;-) >=20 > Andrew >=20