Message ID | 20211112194625.1021072-1-aldyh@redhat.com |
---|---|
State | Committed |
Commit | 264f061997c0a5349cdce6d73f0dc167ac7fc8f4 |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9EDC83858420 for <patchwork@sourceware.org>; Fri, 12 Nov 2021 19:47:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9EDC83858420 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1636746430; bh=Zx++3rMGt3eNESy4o02mC8mUUujU9bagPmlCBqh6tcg=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=Ehk8enOZLmUWo597jbIeZqmi5YVMfb31Z9kpmJWuGUbBG0Lq1Cy+LnmpjpDr7LC4a nEMaiYk0quEm3QcczCkHI5yOC5zBYK0e/CeZw/EQN0lNkBUrOs2ZrISojf/RD8YGxo ygFvXtN4KQRtq36CzQGdo/Owm4b8GY0wFS/kxWZM= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 67AFD3858435 for <gcc-patches@gcc.gnu.org>; Fri, 12 Nov 2021 19:46:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 67AFD3858435 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-424-YC-rLmaMMyGnmYqP-rlf-g-1; Fri, 12 Nov 2021 14:46:34 -0500 X-MC-Unique: YC-rLmaMMyGnmYqP-rlf-g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4D6F587D548 for <gcc-patches@gcc.gnu.org>; Fri, 12 Nov 2021 19:46:33 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.193.141]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 17A26ADD9; Fri, 12 Nov 2021 19:46:29 +0000 (UTC) Received: from abulafia.quesejoda.com (localhost [127.0.0.1]) by abulafia.quesejoda.com (8.16.1/8.15.2) with ESMTPS id 1ACJkR3V1021120 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 12 Nov 2021 20:46:27 +0100 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.16.1/8.16.1/Submit) id 1ACJkR8D1021119; Fri, 12 Nov 2021 20:46:27 +0100 To: GCC patches <gcc-patches@gcc.gnu.org> Subject: [COMMITTED] path solver: Solve PHI imports first for ranges. Date: Fri, 12 Nov 2021 20:46:25 +0100 Message-Id: <20211112194625.1021072-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Aldy Hernandez <aldyh@redhat.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
[COMMITTED] path solver: Solve PHI imports first for ranges.
|
|
Commit Message
Aldy Hernandez
Nov. 12, 2021, 7:46 p.m. UTC
PHIs must be resolved first while solving ranges in a block, regardless of where they appear in the import bitmap. We went through a similar exercise for the relational code, but missed these. Tested on x86-64 & ppc64le Linux. gcc/ChangeLog: PR tree-optimization/103202 * gimple-range-path.cc (path_range_query::compute_ranges_in_block): Solve PHI imports first. --- gcc/gimple-range-path.cc | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
Comments
On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >PHIs must be resolved first while solving ranges in a block, >regardless of where they appear in the import bitmap. We went through >a similar exercise for the relational code, but missed these. Must not all stmts be resolved in program order (for optimality at least)? >Tested on x86-64 & ppc64le Linux. > >gcc/ChangeLog: > > PR tree-optimization/103202 > * gimple-range-path.cc > (path_range_query::compute_ranges_in_block): Solve PHI imports first. >--- > gcc/gimple-range-path.cc | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > >diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc >index b9aceaf2565..71b290434cb 100644 >--- a/gcc/gimple-range-path.cc >+++ b/gcc/gimple-range-path.cc >@@ -365,12 +365,23 @@ path_range_query::compute_ranges_in_block (basic_block bb) > clear_cache (name); > } > >- // Solve imports defined in this block. >+ // Solve imports defined in this block, starting with the PHIs... >+ for (gphi_iterator iter = gsi_start_phis (bb); !gsi_end_p (iter); >+ gsi_next (&iter)) >+ { >+ gphi *phi = iter.phi (); >+ tree name = gimple_phi_result (phi); >+ >+ if (import_p (name) && range_defined_in_block (r, name, bb)) >+ set_cache (r, name); >+ } >+ // ...and then the rest of the imports. > EXECUTE_IF_SET_IN_BITMAP (m_imports, 0, i, bi) > { > tree name = ssa_name (i); > >- if (range_defined_in_block (r, name, bb)) >+ if (gimple_code (SSA_NAME_DEF_STMT (name)) != GIMPLE_PHI >+ && range_defined_in_block (r, name, bb)) > set_cache (r, name); > } >
On Fri, Nov 12, 2021, 20:50 Richard Biener <richard.guenther@gmail.com> wrote: > On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches < > gcc-patches@gcc.gnu.org> wrote: > >PHIs must be resolved first while solving ranges in a block, > >regardless of where they appear in the import bitmap. We went through > >a similar exercise for the relational code, but missed these. > > Must not all stmts be resolved in program order (for optimality at least)? > The recursion takes care of that. Dependencies get taken care of before the definitions that need them. I've yet to see a case where we get it wrong, even in the presence of loops and interdependencies. Well....except in the phis cause we should've done them first. :-) Aldy
On 11/12/21 14:50, Richard Biener via Gcc-patches wrote: > On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >> PHIs must be resolved first while solving ranges in a block, >> regardless of where they appear in the import bitmap. We went through >> a similar exercise for the relational code, but missed these. > Must not all stmts be resolved in program order (for optimality at least)? Generally,Imports are live on entry values to a block, so their order is not particularly important.. they are all simultaneous. PHIs are also considered imports for data flow purposes, but they happen before the first stmt, all simultaneously... they need to be distinguished because phi arguments can refer to other phi defs which may be in this block live around a back edge, and we need to be sure we get the right version. we should look closer to be sure this isn't an accidental fix that leaves the root problem . we need to be sure *all* the PHI arguments are resolved from outside this block. whats the testcase? > >> Tested on x86-64 & ppc64le Linux. >> >> gcc/ChangeLog: >> >> PR tree-optimization/103202 >> * gimple-range-path.cc >> (path_range_query::compute_ranges_in_block): Solve PHI imports first. >> --- >> gcc/gimple-range-path.cc | 15 +++++++++++++-- >> 1 file changed, 13 insertions(+), 2 deletions(-) >> >> diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc >> index b9aceaf2565..71b290434cb 100644 >> --- a/gcc/gimple-range-path.cc >> +++ b/gcc/gimple-range-path.cc >> @@ -365,12 +365,23 @@ path_range_query::compute_ranges_in_block (basic_block bb) >> clear_cache (name); >> } >> >> - // Solve imports defined in this block. >> + // Solve imports defined in this block, starting with the PHIs... >> + for (gphi_iterator iter = gsi_start_phis (bb); !gsi_end_p (iter); >> + gsi_next (&iter)) >> + { >> + gphi *phi = iter.phi (); >> + tree name = gimple_phi_result (phi); >> + >> + if (import_p (name) && range_defined_in_block (r, name, bb)) >> + set_cache (r, name); >> + } >> + // ...and then the rest of the imports. >> EXECUTE_IF_SET_IN_BITMAP (m_imports, 0, i, bi) >> { >> tree name = ssa_name (i); >> >> - if (range_defined_in_block (r, name, bb)) >> + if (gimple_code (SSA_NAME_DEF_STMT (name)) != GIMPLE_PHI >> + && range_defined_in_block (r, name, bb)) >> set_cache (r, name); >> } >>
On Sat, Nov 13, 2021 at 1:51 AM Andrew MacLeod <amacleod@redhat.com> wrote: > > On 11/12/21 14:50, Richard Biener via Gcc-patches wrote: > > On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > >> PHIs must be resolved first while solving ranges in a block, > >> regardless of where they appear in the import bitmap. We went through > >> a similar exercise for the relational code, but missed these. > > Must not all stmts be resolved in program order (for optimality at least)? > > Generally,Imports are live on entry values to a block, so their order is > not particularly important.. they are all simultaneous. PHIs are also > considered imports for data flow purposes, but they happen before the > first stmt, all simultaneously... they need to be distinguished because > phi arguments can refer to other phi defs which may be in this block > live around a back edge, and we need to be sure we get the right version. > > we should look closer to be sure this isn't an accidental fix that > leaves the root problem . we need to be sure *all* the PHI arguments > are resolved from outside this block. whats the testcase? The testcase is the simpler testcase from the PR: https://gcc.gnu.org/bugzilla/attachment.cgi?id=51776 The gist is on a path coming in from BB13: # n_42 = PHI <m_31(13), addr_14(D)(4)> # m_31 = PHI <0(13), m_16(4)> We were solving m_31 first and putting it in the cache, and then the calculation for n_42 picked up this cached m_31 incorrectly. With my patch we do the PHIs first, in whatever gphi_iterator order uses, which I assume is the order in the IL above. However, if PHIs must be resolved simultaneously, then perhaps we need to tweak this. Suppose we flip the definitions: # m_31 = PHI <0(13), m_16(4)> # n_42 = PHI <m_31(13), addr_14(D)(4)> I assume the definition of n_42 should pick up the incoming m_31(13), not one defined in the other PHI. In which case, we could resolve all the PHIs first, but put them in the cache after we're done with all of them. Thoughts? Aldy
On Sat, Nov 13, 2021 at 10:41 AM Aldy Hernandez <aldyh@redhat.com> wrote: > > On Sat, Nov 13, 2021 at 1:51 AM Andrew MacLeod <amacleod@redhat.com> wrote: > > > > On 11/12/21 14:50, Richard Biener via Gcc-patches wrote: > > > On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > >> PHIs must be resolved first while solving ranges in a block, > > >> regardless of where they appear in the import bitmap. We went through > > >> a similar exercise for the relational code, but missed these. > > > Must not all stmts be resolved in program order (for optimality at least)? > > > > Generally,Imports are live on entry values to a block, so their order is > > not particularly important.. they are all simultaneous. PHIs are also > > considered imports for data flow purposes, but they happen before the > > first stmt, all simultaneously... they need to be distinguished because > > phi arguments can refer to other phi defs which may be in this block > > live around a back edge, and we need to be sure we get the right version. > > > > we should look closer to be sure this isn't an accidental fix that > > leaves the root problem . we need to be sure *all* the PHI arguments > > are resolved from outside this block. whats the testcase? > > The testcase is the simpler testcase from the PR: > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=51776 > > The gist is on a path coming in from BB13: > > # n_42 = PHI <m_31(13), addr_14(D)(4)> > # m_31 = PHI <0(13), m_16(4)> > > We were solving m_31 first and putting it in the cache, and then the > calculation for n_42 picked up this cached m_31 incorrectly. > > With my patch we do the PHIs first, in whatever gphi_iterator order > uses, which I assume is the order in the IL above. > > However, if PHIs must be resolved simultaneously, then perhaps we need > to tweak this. Suppose we flip the definitions: > > # m_31 = PHI <0(13), m_16(4)> > # n_42 = PHI <m_31(13), addr_14(D)(4)> > > I assume the definition of n_42 should pick up the incoming m_31(13), > not one defined in the other PHI. In which case, we could resolve all > the PHIs first, but put them in the cache after we're done with all of > them. And lo and behold, a PR just came in exhibiting this exact behavior, saving me from having to come up with a reduced testcase ;-). The testcase in the PR has a path coming in from BB5: # p3_7 = PHI <1(2), 0(5)> # p2_17 = PHI <1(2), p3_7(5)> We're picking up the p3_7 in the PHI when calculating p2_17. Attached is the patch in testing.
On November 13, 2021 10:41:02 AM GMT+01:00, Aldy Hernandez <aldyh@redhat.com> wrote: >On Sat, Nov 13, 2021 at 1:51 AM Andrew MacLeod <amacleod@redhat.com> wrote: >> >> On 11/12/21 14:50, Richard Biener via Gcc-patches wrote: >> > On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >> >> PHIs must be resolved first while solving ranges in a block, >> >> regardless of where they appear in the import bitmap. We went through >> >> a similar exercise for the relational code, but missed these. >> > Must not all stmts be resolved in program order (for optimality at least)? >> >> Generally,Imports are live on entry values to a block, so their order is >> not particularly important.. they are all simultaneous. PHIs are also >> considered imports for data flow purposes, but they happen before the >> first stmt, all simultaneously... they need to be distinguished because >> phi arguments can refer to other phi defs which may be in this block >> live around a back edge, and we need to be sure we get the right version. >> >> we should look closer to be sure this isn't an accidental fix that >> leaves the root problem . we need to be sure *all* the PHI arguments >> are resolved from outside this block. whats the testcase? > >The testcase is the simpler testcase from the PR: > >https://gcc.gnu.org/bugzilla/attachment.cgi?id=51776 > >The gist is on a path coming in from BB13: > > # n_42 = PHI <m_31(13), addr_14(D)(4)> > # m_31 = PHI <0(13), m_16(4)> > >We were solving m_31 first and putting it in the cache, and then the >calculation for n_42 picked up this cached m_31 incorrectly. > >With my patch we do the PHIs first, in whatever gphi_iterator order >uses, which I assume is the order in the IL above. > >However, if PHIs must be resolved simultaneously, then perhaps we need >to tweak this. Suppose we flip the definitions: > > # m_31 = PHI <0(13), m_16(4)> > # n_42 = PHI <m_31(13), addr_14(D)(4)> > >I assume the definition of n_42 should pick up the incoming m_31(13), >not one defined in the other PHI. In which case, we could resolve all >the PHIs first, but put them in the cache after we're done with all of >them. PHI order is irrelevant, they are executed in parallel, thus arguments pick up the old value irrespective of order. Richard. > >Thoughts? >Aldy >
On Sat, Nov 13, 2021 at 2:26 PM Richard Biener <richard.guenther@gmail.com> wrote: > > On November 13, 2021 10:41:02 AM GMT+01:00, Aldy Hernandez <aldyh@redhat.com> wrote: > >On Sat, Nov 13, 2021 at 1:51 AM Andrew MacLeod <amacleod@redhat.com> wrote: > >> > >> On 11/12/21 14:50, Richard Biener via Gcc-patches wrote: > >> > On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > >> >> PHIs must be resolved first while solving ranges in a block, > >> >> regardless of where they appear in the import bitmap. We went through > >> >> a similar exercise for the relational code, but missed these. > >> > Must not all stmts be resolved in program order (for optimality at least)? > >> > >> Generally,Imports are live on entry values to a block, so their order is > >> not particularly important.. they are all simultaneous. PHIs are also > >> considered imports for data flow purposes, but they happen before the > >> first stmt, all simultaneously... they need to be distinguished because > >> phi arguments can refer to other phi defs which may be in this block > >> live around a back edge, and we need to be sure we get the right version. > >> > >> we should look closer to be sure this isn't an accidental fix that > >> leaves the root problem . we need to be sure *all* the PHI arguments > >> are resolved from outside this block. whats the testcase? > > > >The testcase is the simpler testcase from the PR: > > > >https://gcc.gnu.org/bugzilla/attachment.cgi?id=51776 > > > >The gist is on a path coming in from BB13: > > > > # n_42 = PHI <m_31(13), addr_14(D)(4)> > > # m_31 = PHI <0(13), m_16(4)> > > > >We were solving m_31 first and putting it in the cache, and then the > >calculation for n_42 picked up this cached m_31 incorrectly. > > > >With my patch we do the PHIs first, in whatever gphi_iterator order > >uses, which I assume is the order in the IL above. > > > >However, if PHIs must be resolved simultaneously, then perhaps we need > >to tweak this. Suppose we flip the definitions: > > > > # m_31 = PHI <0(13), m_16(4)> > > # n_42 = PHI <m_31(13), addr_14(D)(4)> > > > >I assume the definition of n_42 should pick up the incoming m_31(13), > >not one defined in the other PHI. In which case, we could resolve all > >the PHIs first, but put them in the cache after we're done with all of > >them. > > PHI order is irrelevant, they are executed in parallel, thus arguments pick up the old value irrespective of order. > Ughh, yeah. Just noticed, per my follow-up patch for PR103222. Tested on x86-64 & ppc64le Linux, and pushed. Thanks. Aldy
On Sat, Nov 13, 2021 at 12:55 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > On Sat, Nov 13, 2021 at 10:41 AM Aldy Hernandez <aldyh@redhat.com> wrote: > > > > On Sat, Nov 13, 2021 at 1:51 AM Andrew MacLeod <amacleod@redhat.com> wrote: > > > > > > On 11/12/21 14:50, Richard Biener via Gcc-patches wrote: > > > > On November 12, 2021 8:46:25 PM GMT+01:00, Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > >> PHIs must be resolved first while solving ranges in a block, > > > >> regardless of where they appear in the import bitmap. We went through > > > >> a similar exercise for the relational code, but missed these. > > > > Must not all stmts be resolved in program order (for optimality at least)? > > > > > > Generally,Imports are live on entry values to a block, so their order is > > > not particularly important.. they are all simultaneous. PHIs are also > > > considered imports for data flow purposes, but they happen before the > > > first stmt, all simultaneously... they need to be distinguished because > > > phi arguments can refer to other phi defs which may be in this block > > > live around a back edge, and we need to be sure we get the right version. > > > > > > we should look closer to be sure this isn't an accidental fix that > > > leaves the root problem . we need to be sure *all* the PHI arguments > > > are resolved from outside this block. whats the testcase? > > > > The testcase is the simpler testcase from the PR: > > > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=51776 > > > > The gist is on a path coming in from BB13: > > > > # n_42 = PHI <m_31(13), addr_14(D)(4)> > > # m_31 = PHI <0(13), m_16(4)> > > > > We were solving m_31 first and putting it in the cache, and then the > > calculation for n_42 picked up this cached m_31 incorrectly. > > > > With my patch we do the PHIs first, in whatever gphi_iterator order > > uses, which I assume is the order in the IL above. > > > > However, if PHIs must be resolved simultaneously, then perhaps we need > > to tweak this. Suppose we flip the definitions: > > > > # m_31 = PHI <0(13), m_16(4)> > > # n_42 = PHI <m_31(13), addr_14(D)(4)> > > > > I assume the definition of n_42 should pick up the incoming m_31(13), > > not one defined in the other PHI. In which case, we could resolve all > > the PHIs first, but put them in the cache after we're done with all of > > them. > > And lo and behold, a PR just came in exhibiting this exact behavior, > saving me from having to come up with a reduced testcase ;-). > > The testcase in the PR has a path coming in from BB5: > > # p3_7 = PHI <1(2), 0(5)> > # p2_17 = PHI <1(2), p3_7(5)> > > We're picking up the p3_7 in the PHI when calculating p2_17. > > Attached is the patch in testing. Tested on x86-64 & ppc64le Linux. Pushed.
diff --git a/gcc/gimple-range-path.cc b/gcc/gimple-range-path.cc index b9aceaf2565..71b290434cb 100644 --- a/gcc/gimple-range-path.cc +++ b/gcc/gimple-range-path.cc @@ -365,12 +365,23 @@ path_range_query::compute_ranges_in_block (basic_block bb) clear_cache (name); } - // Solve imports defined in this block. + // Solve imports defined in this block, starting with the PHIs... + for (gphi_iterator iter = gsi_start_phis (bb); !gsi_end_p (iter); + gsi_next (&iter)) + { + gphi *phi = iter.phi (); + tree name = gimple_phi_result (phi); + + if (import_p (name) && range_defined_in_block (r, name, bb)) + set_cache (r, name); + } + // ...and then the rest of the imports. EXECUTE_IF_SET_IN_BITMAP (m_imports, 0, i, bi) { tree name = ssa_name (i); - if (range_defined_in_block (r, name, bb)) + if (gimple_code (SSA_NAME_DEF_STMT (name)) != GIMPLE_PHI + && range_defined_in_block (r, name, bb)) set_cache (r, name); }