From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by sourceware.org (Postfix) with ESMTPS id 9D842386F419 for ; Thu, 27 Aug 2020 08:54:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9D842386F419 Received: by mail-ed1-x542.google.com with SMTP id f24so4179971edw.10 for ; Thu, 27 Aug 2020 01:54:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JwX1NHLVEzg37ijN0FNnX0/9CTFIyD4yE5G8h4wrIeI=; b=MmFqKOEC866hLO9gzf0EhFzygpLQgKQYAr71kyfHZtChxLSms7IruQwJhYY3TwO71q QkpgbbJj6IeUAwhttsKgv9k60Hor3meT/2rrRsU6yh8rcySklhs3i1kyvWpCPSiBkMya rxpK22BI2iXBvGh0QcyVLpTkAjS1h5zhPmiit22qDnz38BIoxaurpX0FiE65mTkhA4Ue r0iRiiv0JEs9IZ/rL3IcuHXLlBjj+3dHupOM6ONjx81IxPhL05lpfcHfZSfi2IARept8 HvK7fXgfRqm6H1V9/RuI61D60z/ulEkdnBnAw4Vsk2odo8FykhwObrjPfyxuBNjPn5KH 4LxQ== X-Gm-Message-State: AOAM5325hR/DLScNMRmnhVPJ0QBYYjptnA+gNzeGLyV9cKsU9vZwGfOi 9m8oeYeNFuRfPlxpuMAyeafyoxqQaVOBCTc2GBg= X-Google-Smtp-Source: ABdhPJzZ029WeuBAMhWsthARVMbPgT5gswHhVRrCXZ1Gm6CizUbokBAzsYtx9+raCYtdaeGG/zogPQk0mTMb4rMZvp0= X-Received: by 2002:a50:82c7:: with SMTP id 65mr19469898edg.138.1598518456719; Thu, 27 Aug 2020 01:54:16 -0700 (PDT) MIME-Version: 1.0 References: <8bf8b90a-6d10-90e3-62aa-633f7bbf71be@suse.cz> <34bd3626-39c0-2516-208d-0ebf5a736b1c@suse.cz> <20200727111104.GB84823@kam.mff.cuni.cz> <0011f4a6-7ece-47f6-e864-f837216f71c7@suse.cz> <84b9586d-63da-18bd-9113-05597520d58c@suse.cz> <4fab8070-5eff-1f2c-b916-8af1101fd0f9@suse.cz> <5a10c74882a35cae5089b8b82aa96c3cf5800ed2.camel@redhat.com> In-Reply-To: <5a10c74882a35cae5089b8b82aa96c3cf5800ed2.camel@redhat.com> From: Richard Biener Date: Thu, 27 Aug 2020 10:54:05 +0200 Message-ID: Subject: Re: [PATCH 3/3] vec: use inexact growth where possible. To: Jeff Law Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , GCC Patches , Jan Hubicka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.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: Thu, 27 Aug 2020 08:54:19 -0000 On Wed, Aug 26, 2020 at 11:02 PM Jeff Law wrote: > > On Tue, 2020-08-11 at 13:37 +0200, Martin Li=C5=A1ka wrote: > > From cc1d41a469d76f2f8e4f44bed788ace77a1c6d62 Mon Sep 17 00:00:00 2001 > > From: Martin Liska > > Date: Mon, 10 Aug 2020 12:09:19 +0200 > > Subject: [PATCH 3/3] vec: use inexact growth where possible. > > > > gcc/ChangeLog: > > > > * cfgrtl.c (rtl_create_basic_block): Use default value for > > growth vector function. > > * gimple.c (gimple_set_bb): Likewise. > > * symbol-summary.h: Likewise. > > * tree-cfg.c (init_empty_tree_cfg_for_function): Likewise. > > (build_gimple_cfg): Likewise. > > (create_bb): Likewise. > > (move_block_to_fn): Likewise. > I'll note that in some cases we were avoiding exponential growth in our n= ew size > computations. Presumably the inexact growth support will do something si= milar, > even if it's not exactly the same. Right? Assuming that's the case this= is OK > too. @@ -183,12 +183,12 @@ init_empty_tree_cfg_for_function (struct function *fn= ) last_basic_block_for_fn (fn) =3D NUM_FIXED_BLOCKS; vec_alloc (basic_block_info_for_fn (fn), initial_cfg_capacity); vec_safe_grow_cleared (basic_block_info_for_fn (fn), - initial_cfg_capacity, true); + initial_cfg_capacity); /* Build a mapping of labels to their associated blocks. */ vec_alloc (label_to_block_map_for_fn (fn), initial_cfg_capacity); vec_safe_grow_cleared (label_to_block_map_for_fn (fn), - initial_cfg_capacity, true); + initial_cfg_capacity); this is odd now at least since we explicitely alloc initial_cfg_capacity. IMHO we should instead use basic_block_info_for_fn (fn)->quick_grow_cleared (initial_cfg_capacity) here? The rest looks OK and along the plan. Thanks, Richard. > jeff >