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 ESMTP id 3D02B3896810 for ; Mon, 7 Jun 2021 19:20:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D02B3896810 Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-96-P1TzqKHMM327kU5QY18Ghw-1; Mon, 07 Jun 2021 15:20:19 -0400 X-MC-Unique: P1TzqKHMM327kU5QY18Ghw-1 Received: by mail-qk1-f200.google.com with SMTP id o14-20020a05620a130eb02902ea53a6ef80so13490160qkj.6 for ; Mon, 07 Jun 2021 12:20:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vZRTTegDe3E5AyT8G8n0zWkUY7TbaK8QTMj6IeZIoYY=; b=CXLDC9EuSjmrZBrKEGfj4Uoej7cr/zNSXhQ8AwYd+j87wRbNjQnM6+k+DPugHB3nGc piGzNm3v56ju5sPj3gk0/qidzVMg4wZFEHwVnJlAXA85Ns9PurO2iMpOqwr6vyyEFaux I2Xu8Uorwe83SyHtg96Dcc0/uzZMo6Jj8Qc2Au2Ug8D4nBNw7iaG/YfI/bF7X6X13RGa 2TsvHJnO9+J0gAszoin/WZGtW51lnE39sWfz2izWJ/C998qfZow3B60F7o4Yuy1sfDb5 kaAdxL6IZUNlZ9z1oit+noLLN28E5fWaOWC+MycMIhFqDEPXBhfh1PPblm9IZKXBZAU/ 4IDw== X-Gm-Message-State: AOAM533/cdSdYmDSlo/BwPs/r+7f3t8u3ODDCkIqockAGcMEDGUJDwc1 XbguCCqnqMU5c9zm0igSwdvabXR73quMPELfNZP/UUP7Sze9qyVyWGH/sMj8egbwpGg7eBze2nU WqdAWzim3HTQZ8wa2BI1qtw2wpk27ympgeljoMatPESIMt52bHTE08Kg4/rDVm7AjW4umQA== X-Received: by 2002:a0c:e88b:: with SMTP id b11mr1756868qvo.59.1623093618127; Mon, 07 Jun 2021 12:20:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwoXjS+zjlUnLHnUlYFACaXugzN0/JFV00a6CCJwpgzO1lnhb9NkoXBQypF9Vfr0b1IvKocIQ== X-Received: by 2002:a0c:e88b:: with SMTP id b11mr1756833qvo.59.1623093617779; Mon, 07 Jun 2021 12:20:17 -0700 (PDT) Received: from ?IPv6:2607:fea8:a25d:e700::1b2a? ([2607:fea8:a25d:e700::1b2a]) by smtp.gmail.com with ESMTPSA id b132sm7260497qkg.116.2021.06.07.12.20.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 12:20:17 -0700 (PDT) Subject: Re: [PATCH] Implement a context aware points-to analyzer for use in evrp. To: Richard Biener , Aldy Hernandez Cc: GCC patches References: <20210607101003.615929-1-aldyh@redhat.com> From: Andrew MacLeod Message-ID: <981fd233-3815-5e12-bb34-69fcd4fbadf9@redhat.com> Date: Mon, 7 Jun 2021 15:20:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-CA X-Spam-Status: No, score=-5.2 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_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 19:20:24 -0000 On 6/7/21 9:30 AM, Richard Biener via Gcc-patches wrote: > On Mon, Jun 7, 2021 at 12:10 PM Aldy Hernandez via Gcc-patches > wrote: >> The substitute_and_fold_engine which evrp uses is expecting symbolics >> from value_of_expr / value_on_edge / etc, which ranger does not provide. >> In some cases, these provide important folding cues, as in the case of >> aliases for pointers. For example, legacy evrp may return [&foo, &foo] >> for the value of "bar" where bar is on an edge where bar == &foo, or >> when bar has been globally set to &foo. This information is then used >> by the subst & fold engine to propagate the known value of bar. >> >> Currently this is a major source of discrepancies between evrp and >> ranger. Of the 284 cases legacy evrp is getting over ranger, 237 are >> for pointer equality as discussed above. >> >> This patch implements a context aware points-to class which >> ranger-evrp can use to query what a pointer is currently pointing to. >> With it, we reduce the 284 cases legacy evrp is getting to 47. >> >> The API for the points-to analyzer is the following: >> >> class points_to_analyzer >> { >> public: >> points_to_analyzer (gimple_ranger *r); >> ~points_to_analyzer (); >> void enter (basic_block); >> void leave (basic_block); >> void visit_stmt (gimple *stmt); >> tree get_points_to (tree name) const; >> ... >> }; >> >> The enter(), leave(), and visit_stmt() methods are meant to be called >> from a DOM walk. At any point throughout the walk, one can call >> get_points_to() to get whatever an SSA is pointing to. >> >> If this class is useful to others, we could place it in a more generic >> location. >> >> Tested on x86-64 Linux with a regular bootstrap/tests and by comparing >> EVRP folds over ranger before and after this patch. > Hmm, but why call it "points-to" - when I look at the implementation > it's really about equivalences. Thus, > > if (var1_2 == var2_3) > > could be handled the same way. Also "points-to" implies (to me) > that &p[1] and &p[2] point to the same object but your points-to > is clearly tracking equivalences only. > > So maybe at least rename it to pointer_equiv_analyzer? ISTR > propagating random (symbolic) equivalences has issues. Yeah, pointer_equiv is probably more accurate. This is purely for cases where we know a pointer points to something that isn't an ssa_name.  Eventually this is likely to be subsumed into a pointer_range object, but unlikely in this release. I don't think this is actually doing the propagation though... It tracks that a_2 currently points to &foo.. and returns that to either simplifier or folder thru value_of_expr().  Presumably it is up to them to determine whether the tree expression passed back is safe to propagate.   Is there any attempt in EVRP to NOT set the range of something to [&foo, &foo] under some conditions?   This is what the change amounts to.  Ranger would just return a range of [1, +INF], and value_of_expr  would therefore return NULL.  This allows value_of to return &foo in these conditions.   Aldy, did you see any other checks in the vr-values code? Things like   if (var1_2 == var2_3) deal with just ssa-names and will be handled by an ssa_name relation oracle. It just treats equivalencies like a a slightly special kind of relation. Im just about to bring that forward this week. Andrew