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 3A0D53851514 for ; Fri, 28 Oct 2022 13:59:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3A0D53851514 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=1666965562; 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=AhUL8qAtse4HCHV4PwVfLKRYeQbHZW81ktDRoIq+f3I=; b=SitrZ/87oalRgdgGNsTnN6gcvF59ovLy4CHRr0jkozgy/fGHl8/IGQOwsi8PFmCIzjNzMK pkGhweDOrjk1ch+wUz6KQ+W0+kOx7+n3TK7leqHoZQXmbfrfIvs4D5lDW55FJjYezIFptS OZHkDabYZYYsenuskvagwyF3a6u38fg= Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-635-CPH-RWJDNryvPvTaFKS4LA-1; Fri, 28 Oct 2022 09:59:20 -0400 X-MC-Unique: CPH-RWJDNryvPvTaFKS4LA-1 Received: by mail-io1-f69.google.com with SMTP id a14-20020a6b660e000000b006bd37975cdfso4406048ioc.10 for ; Fri, 28 Oct 2022 06:59:20 -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=AhUL8qAtse4HCHV4PwVfLKRYeQbHZW81ktDRoIq+f3I=; b=XiIbx2+X82b1+lXB2yERo3Fi3avtOKgROhj36ZRY44kuuw7gwpCNi8l2I7iNC2o3pa BFbY1N1UeDFbJEpPEg8yxDdrnhV71LhaqoIQZarH6KnbvLoF66QmT91gX2MGRiTsmckA jKS/+s49ITX8kP424EHsXkmPXbshhoWz0w7PacBUrfLfucZmkrtlzG7ZwZ0T1BcOjzpN 90er0Q8bJVvFDNC079/BzX3fg0fqzScac0x2yW4TJjGe5ZYj7YaIHYpSNIHDx6KgfaKD w1YtHT6HvznwMVOBEIhvKUalM6gJs0EnGaNAbcVBaWz+qSPUxz6jN0zkYOJ6HDTSrVqo 29hA== X-Gm-Message-State: ACrzQf1FUFKbuf4ByhOrgf/9THneSH32LLUytIYTeron875+fG+pV8mg h08fn2/CsXs/QoF2Xubnpw7AAKMLZQ9mVE27cDzVjrCzczSBVFMfvm/yYbhTxpfoctRmS65qlkt /KT0Z3ayG4oSFKLV5iw== X-Received: by 2002:a02:cc18:0:b0:374:507b:8c16 with SMTP id n24-20020a02cc18000000b00374507b8c16mr16743950jap.296.1666965560082; Fri, 28 Oct 2022 06:59:20 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5su7SKH5uPG2+dGKcZ/93Vi75c5tfUtCiqhCPGjlNUscBY4aqbWkWgqS8MXvYiBzR14zaATQ== X-Received: by 2002:a02:cc18:0:b0:374:507b:8c16 with SMTP id n24-20020a02cc18000000b00374507b8c16mr16743938jap.296.1666965559828; Fri, 28 Oct 2022 06:59:19 -0700 (PDT) Received: from ?IPV6:2607:fea8:a263:f600::72c3? ([2607:fea8:a263:f600::72c3]) by smtp.gmail.com with ESMTPSA id x38-20020a0294a9000000b0036ee761e2f4sm1685883jah.159.2022.10.28.06.59.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 06:59:19 -0700 (PDT) Message-ID: <9588af4d-7c77-fad3-b845-9880139e28b1@redhat.com> Date: Fri, 28 Oct 2022 09:59:17 -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 , Eric Botcazou Cc: gcc-patches , "hernandez, aldy" , Jakub Jelinek , Jeff Law References: <44fdc256-0326-0859-98bf-5ceb89578658@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=-5.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 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. It appears that leaving those until VRP2 works fine...  testsuite currently running tho ;-) Andrew