From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 9C9AC3858D37 for ; Sun, 26 Mar 2023 18:00:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C9AC3858D37 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-pj1-x1030.google.com with SMTP id r7-20020a17090b050700b002404be7920aso5690781pjz.5 for ; Sun, 26 Mar 2023 11:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679853613; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=4EOv0p1s4tBGPdws+PzHOZn922Ow/QVyUopgKBZNw2A=; b=LQaXRWcjaw/4ndweg+I29kJhmCI81qruU/nR1MSL7ipgmkuumNOvpFrcFlhW6oKidn DosnZYohxMZTjr4zCuP+R3CscRa+RvIthjjXpzcFpfRlIGz61yhRirVn5Dhzn/mdyoP1 rGV3QqGnKe6PW4zXWVhyXnyBuj2ETwu7imzz09AE+KIGhVzw/ovDxyts/qSv/iFSudlG VJo3N05RNkrlBRsuR/HbaEfNTjExMWP58zR/zYBIqQZeJEJVuOeIOjswWp7fcO8a3FLM +30F1BIzq4pm1Lv+Wzl80dd42TL4q3FRZFUdKW/WijFEpimkq6nJQHQVaJmA21M27WUT b+Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679853613; 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=4EOv0p1s4tBGPdws+PzHOZn922Ow/QVyUopgKBZNw2A=; b=LsODWC/rXCfU1FkFmzQu3D2lq6npK4M5FXebCQzvkE1l1Kyz5H44b8DUCupewYMOtw QHyIXC/lwQtsIk/4CzfNwmob1hwUYIa0BfNdMkZiOQmthNb6FFS5EZCBcSjcSHxGAHpS qFiBmq9pcQ3EsYuh9wHQisu/wrdxAsAE7KnXBuID2vl8yaU5ZgCzNrJqUR+ps8hzBLsd 0Ds3y6HxSYTs4pp/kQxqnA6HPzxrVQNmKlOTvCl10qenHjY4MeJD7z/9WQDlqcYiq1xB TH4x42EdwcaRwgVhozogv7k2QdYnBVyJzxE8tRNxYkUEaIfCBXLxwMxRpc6W1LkNKtKn dH0w== X-Gm-Message-State: AAQBX9dKDQAV2Iou+VEe6IZnUBsuqf07CqxxxchrazJNxiQ63VXBwL// m+Ez/izpmw28ATbYwjF3Wlc= X-Google-Smtp-Source: AKy350ajUJBRcEMoUI+/Iv4sIzRjAgSmxl5gDxkTofD583/3FKxSDT8ibelJo8e2qmMxd6zQ8/s1rA== X-Received: by 2002:a17:903:11cf:b0:1a2:1c7:1c38 with SMTP id q15-20020a17090311cf00b001a201c71c38mr10844749plh.54.1679853613528; Sun, 26 Mar 2023 11:00:13 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id x21-20020a170902ea9500b0019c2cf12d15sm17568140plb.116.2023.03.26.11.00.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 11:00:13 -0700 (PDT) Message-ID: Date: Sun, 26 Mar 2023 12:00:11 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] tree-optimization/109237 - last_stmt is possibly slow Content-Language: en-US To: Richard Biener , gcc-patches@gcc.gnu.org Cc: Jakub Jelinek References: <20230322123006.A480C3858296@sourceware.org> From: Jeff Law In-Reply-To: <20230322123006.A480C3858296@sourceware.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 3/22/23 06:29, Richard Biener via Gcc-patches wrote: > Most uses of last_stmt are interested in control transfer stmts > and for the testcase gimple_purge_dead_eh_edges shows up in > the profile. But last_stmt looks past trailing debug stmts but > those would be rejected by GIMPLEs verify_flow_info. The following > adds possible_ctrl_stmt besides last_stmt which does not look > past trailing debug stmts and adjusts gimple_purge_dead_eh_edges. > > I've put checking code into possible_ctrl_stmt that it will not > miss a control statement if the real last stmt is a debug stmt. > > The alternative would be to change last_stmt, explicitely introducing > last_nondebug_stmt. I remember we chickened out and made last_stmt > conservative here but not anticipating the compile-time issues this > creates. I count 227 last_stmt and 12 last_and_only_stmt uses. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Any opinions? I probably lean towards s/last_stmt/last_nondebug_stmt/ > in next stage1 and then adding last_stmt and changing some > uses back - through for maintainance that's going to be a > nightmare (or maybe not, a "wrong" last_stmt should be safe to > backport and a last_nondebug_stmt will fail to build). Sounds quite sensible to me. 227+12 isn't terrible and I bet the vast majority, should be safe for last_nondebug_stmt. > > Richard. > > PR tree-optimization/109237 > * tree-cfg.h (possible_ctrl_stmt): New function returning > the last stmt not skipping debug stmts. > (gimple_purge_dead_eh_edges): Use it. OK jeff