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 E20F73858D39 for ; Thu, 21 Oct 2021 07:42:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E20F73858D39 Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-37-AbCZD34bNX2JFWahCyPVWQ-1; Thu, 21 Oct 2021 03:42:33 -0400 X-MC-Unique: AbCZD34bNX2JFWahCyPVWQ-1 Received: by mail-lf1-f69.google.com with SMTP id z18-20020a0565120c1200b003fd76d7ca21so4265837lfu.13 for ; Thu, 21 Oct 2021 00:42:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/+5WgOqAXh4wRsvy4FXzjOjoL/eTgqXnz/ZRCkdtpI4=; b=meJNGVlCD62l9x1iuDTI+oLzb0FpfHWEljXfjAjSxjEkVto7jgCPvNgHfOgbwExLnG 370HeBCowQKj/IixBoiD3YcZJgB9ZnMcC/pGPW9yU2zeU2fCgC7KwlOjLDFjI8ZXklyd DEmtVq14kkiUO0WIrwQRX2KHBITnCw9h9M1eDGdzADkfHiRrxCIZ61uvM7MToA+mEwUw gNhEfGyReqpes0SjAfqFa5wE2tUftCW9EUBk9aHa2gmXQ4dEgA95Og07ST1dx2OOl0Br eAixfE6DahzP4N8Gb3xotqump3Ro0WK2BP53q0E7wS45uHqFZ7mcW4AJi2h2OUZHWVIT 5fIA== X-Gm-Message-State: AOAM530sjnR84v86KUtqDpu65go7XAEhAKPhTCGJdyLq7hxFCM3vc6EK MzyQ+EWENr8/iBZRyW8lx99lr71+keXgy5ngd2ZGcXo6LiJDsxM8OrP+LFOyRNtvQr+xBasiIG3 U4WVLHQvyo0O1ZlETera8u3r7qALFWzvKjg== X-Received: by 2002:a05:6512:360a:: with SMTP id f10mr3981002lfs.445.1634802151614; Thu, 21 Oct 2021 00:42:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0FZtQE7hn+i0eUYqxCwaLjPUdG3eQcsu8h8Hk8OmpvRrfXMEjAjOi+sXl/Q3pmfcju/y/iZXx4AdZ/kM6/eQ= X-Received: by 2002:a05:6512:360a:: with SMTP id f10mr3980982lfs.445.1634802151335; Thu, 21 Oct 2021 00:42:31 -0700 (PDT) MIME-Version: 1.0 References: <20211008151222.37790-1-aldyh@redhat.com> <49371bdc-edd7-a5fa-4d75-9b2ed51478ad@gmail.com> <88f397a8-78d1-fe74-c221-e846072edff1@redhat.com> <49b035a6-7160-07d9-0c34-4accdebc1af4@gmail.com> In-Reply-To: <49b035a6-7160-07d9-0c34-4accdebc1af4@gmail.com> From: Aldy Hernandez Date: Thu, 21 Oct 2021 09:42:20 +0200 Message-ID: Subject: Re: [PATCH] Convert strlen pass from evrp to ranger. To: Jeff Law Cc: Jakub Jelinek , GCC patches , Andrew MacLeod , Richard Biener X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 21 Oct 2021 07:42:36 -0000 > Massaging the IL should only take two forms IIRC. > > First, if we have a simplification we can do. That could be const/copy > propagation, replacing an expression with an SSA_NAME or constant and > the like. It doesn't massage the IL just to massage the IL. > > Second, we do temporarily copy propagate the current known values of an > SSA name into use points and then see if that allows us to determine if > a statement is already in the hash tables. But we undo that so that > nobody should see that temporary change in state. > > Finally, it does create some expressions & statements on the fly to > enter them into the tables. For example, if it sees a store, it'll > create a load with the source & dest interchanged and enter that into > the expression table. But none of this stuff ever shows up in the IL. > It's just to create entries in the expression tables. > > So ITSM the only real concern would be if those temporary const/copy > propagations were still in the IL and we called back into Ranger and it > poked at that data somehow. Hmmm, this is all very good insight. Thanks. One thing that would have to be adjusted then is remove the enable_ranger() call in the patch. This sets a global ranger, and there are users of get_range_query() that will use it to get on-demand ranges. One such use that I added was ssa_name_has_boolean_range in tree-ssa-dom.c. This means that if the IL has been temporarily changed, this function can and will use the global ranger. The alternative here would be to just create a new local ranger: - gimple_ranger *ranger = enable_ranger (fun); + gimple_ranger *ranger = new gimple_ranger; and then obviously deallocate it at the disable_ranger call site. This will cause any users of get_range_query() in the compiler to just use global ranges. Hopefully, none of these downstream users of get_range_query() from DOM need context sensitive results. ssa_name_has_boolean_range?? I think what you'd need to do is check that there are no calls to the ranger from cprop_into_stmt (?? this is the place where IL changes??), until wherever the undoing happens (I couldn't find it). I see a call to simplify_using_ranges in optimize_stmt that looks like it could be called with the IL in mid-flight. Maybe this call needs to happen before the IL is altered? > So if we're referring to those temporary const/copy propagations > "escaping" into Ranger, then I would fully expect that to cause > problems. Essentially they're path sensitive const/copy propagations > and may not be valid on all the paths through the CFG to the statement > where the propagation occurs Yeah. disabling the global ranger should help, plus making sure you don't use the ranger in the midst of the path sensitive changes. Aldy