From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 80895385151F for ; Fri, 28 Oct 2022 13:46:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 80895385151F 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-x531.google.com with SMTP id a13so7993773edj.0 for ; Fri, 28 Oct 2022 06:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=K7VSa3uvhF7MBU1Oq04ysOqWyC67bULhVlHwmKxZLZI=; b=INz/JYxWm8t3YA/pN315TIXWZuX9bq/TEXc2BL5DC9XiGserWZrpCl5LborrjA95P3 XzFXKy0MAHPZ5JJU5qupjcUi+U8SB8rmkQqCaKtVIAVqqcIafsGlQmbFNWC3lFZq/4c0 bhTm0k+byUr5CTEYixvgvZHWccx4zynIV6F9tLby3ZVeHSxzswF3Buym+OzrSjnjiaaF cUKHOYgxNCIjq6+IgL0Ve9LFet+wcbTQ4g4oK6C5STSKV5A1MqY7Orfi7nsggXadG9yP ZmGHDl2BBUh2j1PUZ0Q5de1QmVQD+oxO1dHpAPm5bXb5X+0jBMHCI40mO4P7rbmKdmVC liOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=K7VSa3uvhF7MBU1Oq04ysOqWyC67bULhVlHwmKxZLZI=; b=iFukZI7Pc3cyC/WEt0UgwyTlHY/TwVtjGpzdjKH3foOQq2sj8awx1xlKwnaMIzlRuG Ovgo6uXaJ4NUngu/nnoa4xAd7H/hdBcJVCr+oIh8mYM8gGwKJI83BBAtpD5p8l5v03pV B6oF0YAO4LFMob3fhsJEtcgeNVylkv4VILf7b+qBSiIvOlR84hPb3bSjaztc8KRzlQ4t +9EMa4nLrzaPKNxbKk1D0ghIaWErAvMizQHPpgKjJw5aGUR1aYYYDeRa6oUfIt2ML0fU 550lHrPBB9dE2j9y7uGc+5EANO2BQpPFE87eRyfH0boUm0+kxkilhqQfJsj/3dsNgFnJ e2sg== X-Gm-Message-State: ACrzQf0EICNCJUIhNdN1hG0+3mFqMtDyza+4V9MwMe1hJF4J9qciNFhn PFeYVFkzMigSnRvT9DqsO/zrHM7icUFDNUmrf8g= X-Google-Smtp-Source: AMsMyM661mF0mfCZa//RPcmysiOa69G+yAJm9gY7Pim05IEVcdli7bA16mUFpCWYwg1yzrlLj+utSOp/6Eu0mJaU10w= X-Received: by 2002:aa7:d8c4:0:b0:461:8d31:41fc with SMTP id k4-20020aa7d8c4000000b004618d3141fcmr30056137eds.202.1666964786125; Fri, 28 Oct 2022 06:46:26 -0700 (PDT) MIME-Version: 1.0 References: <44fdc256-0326-0859-98bf-5ceb89578658@redhat.com> In-Reply-To: <44fdc256-0326-0859-98bf-5ceb89578658@redhat.com> From: Richard Biener Date: Fri, 28 Oct 2022 15:46:14 +0200 Message-ID: Subject: Re: RFC - VRP1 default mode To: Andrew MacLeod , Eric Botcazou Cc: gcc-patches , "hernandez, aldy" , Jakub Jelinek , Jeff Law Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 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: 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? > bultin_unreachables() from switches get removed during the second pass > of switch-conversion... which I presume remains OK. > > Anyway, thats pretty much under control. Patch probably coming later today. > > > > >> There is one test case that needs adjustment for > >> that which was just checking for a mask in DOM2 > >> (gcc.dg/tree-ssa/pr107009.c). At this point I have not aware of > >> anything that Id be concerned about, and the testsuite seems to run > >> cleanly. > > Did you enable Ada? The only feature I don't see implemented is > > symbolic range handling which boils down to general base + constant offset > > range endpoints (that's what symbolic ranges allow). That area was > > specifically improved to optimize range checks emitted by the Ada frontend > > but IIRC also applies to fortran -frange-check (not sure about test coverage > > of that). > I get a clean testsuite run configured and bootstrapped with > > --enable-languages=c,c++,go,fortran,ada,obj-c++,jit --enable-host-shared > > Is there a PR or specific tests in either fortran or ada for those > improvements? ie, something specific I should check for? Part of rangers > point is to be able to do symbolic relationships without storing the > symbolic in the range, just picking it up from the IL as needed. I'm defering to Eric here. Richard. > Andrew > >