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 300083851514 for ; Fri, 28 Oct 2022 14:33:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 300083851514 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=1666967623; 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=9egRXiywUqRasNackXsOTbt1Cf5XI3jPC3Bps7aQf0Q=; b=WUoXhHeeor8FB1zZI+vXdsev9lsPLMa2oeolAkFJZ4g1guft9uiIqnGoWnxx9BFEYs5CL0 m1458h8xIhdHXPPUdEDVwv85g4pP5snoOiKYtwBska52PngzpXsOwzmYwaGRT+/CczNv7D JJEAKxLzG6cj6PWJlEyyuCtqQNEYoj0= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-604-GSHI3b4_Neqn3bdtTDtbYQ-1; Fri, 28 Oct 2022 10:33:41 -0400 X-MC-Unique: GSHI3b4_Neqn3bdtTDtbYQ-1 Received: by mail-il1-f198.google.com with SMTP id s2-20020a056e021a0200b0030087a59cf9so1379312ild.11 for ; Fri, 28 Oct 2022 07:33:41 -0700 (PDT) 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=9egRXiywUqRasNackXsOTbt1Cf5XI3jPC3Bps7aQf0Q=; b=MOPODizvkKBe4pdc1KTjOyMNhIRCiltNbNmHHAu8IeMH+YuQVezUeL4z1PO93POWk5 qWZrIoeYTpTOWYTTA7GFXzCd5FoljNSZK2LeOlsrxwuAC35lP//WMLRJPXoWGb8U9wSE R1m8esPZs0DDCX6bf/eeuNN9iNYQT6DkdEbEPxofDuZQ88FtkaAVEbN4kPPraQYKHwGP PFNqVN0V3HBrwe/ts1SewK6qZwLhYwnN/5yFYeGDHBAeYBEhZVZYmUiWahe3ptOBrHcC uFrU0AsF70V3AUWPuNp77eJyKDFsKEmxsYRaRUpWlPKwlllLrgY+mF/6KA2smBA6YTqY +3Zg== X-Gm-Message-State: ACrzQf1SURcIKGydd6qnNWB+d5cxp1aQuFIaJlv5FypQ89BR11H6FxmN MfApIWYGwKJq7hpxT2kL1/i3mcazvRG6fTq9ml9fISd3QCdHzJ4QoyWoysq2qAKalpu+T5JZclG ZUVd/+tgw5G/ZY9Jssw== X-Received: by 2002:a02:cf8f:0:b0:373:9526:ff08 with SMTP id w15-20020a02cf8f000000b003739526ff08mr18457667jar.298.1666967620817; Fri, 28 Oct 2022 07:33:40 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4Kxfpi0o3mT97WG90AyvFtjfBKMfP7w4NREB6/MpkkGVObWzAQ+9iUJ0ZqX3QmigvZL6mp5w== X-Received: by 2002:a02:cf8f:0:b0:373:9526:ff08 with SMTP id w15-20020a02cf8f000000b003739526ff08mr18457644jar.298.1666967620553; Fri, 28 Oct 2022 07:33:40 -0700 (PDT) Received: from ?IPV6:2607:fea8:a263:f600::72c3? ([2607:fea8:a263:f600::72c3]) by smtp.gmail.com with ESMTPSA id t24-20020a02b198000000b0036c8a246f54sm1742264jah.142.2022.10.28.07.33.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 07:33:40 -0700 (PDT) Message-ID: <1324a415-a50b-d360-6a27-a2b0faf885f0@redhat.com> Date: Fri, 28 Oct 2022 10:33:38 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: RFC - VRP1 default mode To: Richard Biener Cc: Eric Botcazou , gcc-patches , "hernandez, aldy" , Jakub Jelinek , Jeff Law References: <9588af4d-7c77-fad3-b845-9880139e28b1@redhat.com> <6C3EA0FC-6B7B-4E8D-8044-CF44407BB56C@gmail.com> From: Andrew MacLeod In-Reply-To: <6C3EA0FC-6B7B-4E8D-8044-CF44407BB56C@gmail.com> 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=-5.3 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 10/28/22 10:14, Richard Biener wrote: > >> Am 28.10.2022 um 15:59 schrieb Andrew MacLeod : >> >>  >>> On 10/28/22 09:46, Richard Biener wrote: >>>> On Fri, Oct 28, 2022 at 3:43 PM Andrew MacLeod wrote: >>>> >>>> On 10/28/22 03:17, Richard Biener wrote: >>>>> On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod wrote: >>>>>> Figured I would ask what you guys think of making ranger the default for >>>>>> the VRP1 pass now. >>>>>> >>>>>> 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 done >>>>>> in the DOM passes now anyway... so it just happens slightly later in the >>>>>> 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 () >>>> >>>> idiom and set the appropriate global ranges, but it has to leave those >>>> with 2 ssa-names: >>>> >>>> if (a_1 != b_2) >>>> __builtin_unreachable() >>>> >>>> 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? >> So as I looked at builtin_unreachable(), it was very adhoc. That one of the roots of that artificial testcase in the PR I opened. Cascading calls were 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 PR that Uli opened that Aldy fixed, I could make fail again with minor adjustments to the conditions. So I worked on a consistent approach. >> >> My guess is the old range stored globally for that case for a_1 was probably ~[b_2, b_2] meaning it was carried in the range. Until we have an overall global relation tracker, we can't represent that across passes. > The global ranges were never symbolic, this was at most used during VRP itself. > > Ah. Just took a closer look at what use to happen. legacy vrp1 never removed the unreachable call, it hung around until the threadfull2 ran just before vrp2. The testcase was an artificial vectorizing test with an infinite loop and unreachable in the final block.  Just part of the inconsistent removal :-P: Andrew