This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Avoid an unwanted decl re-map in copy_gimple_seq_and_replace_locals
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Tue, 12 Jan 2016 19:14:33 +0100
- Subject: Re: [patch] Avoid an unwanted decl re-map in copy_gimple_seq_and_replace_locals
- Authentication-results: sourceware.org; auth=none
- References: <20160108145901 dot GD3982 at virgil dot suse dot cz> <CAFiYyc3_T3BOs-n6qVxv-11ZRYT1N+zs79p4azmjhHN2ZpNTug at mail dot gmail dot com> <20160111163847 dot GX18720 at tucnak dot redhat dot com> <20160112173621 dot GF3982 at virgil dot suse dot cz> <20160112175131 dot GG3982 at virgil dot suse dot cz>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jan 12, 2016 at 06:51:31PM +0100, Martin Jambor wrote:
> On Tue, Jan 12, 2016 at 06:36:21PM +0100, Martin Jambor wrote:
> > > remap_decl (old_var, id);
> > > }
> > > - phase 2 - do the full remap_decls, but during that arrange that
> > > remap_decl for non-zero id->remapping_type_depth if (!n) just returns
> > > decl
> >
> > ...they would not be copied here because remap_decl would not be
> > duplicating stuff. So I'd end up with an original local decl when I
> > actually need a duplicate.
> >
>
> ugh, I'm trying to be too fast and obviously forgot about the
> id->remapping_type_depth part of the proposed condition.
>
> Still, when could relying solely on id->remapping_type_depth fail?
Well, those functions are used for numerous purposes, and you'd only
want to not remap decls if not already remapped if id->remapping_type_depth
when inside of the copy_gimple_seq_and_replace_locals
path (and only for the remap_decls in there), so you need IMHO some
flag to distinguish that.
And the reason for the above suggested 2 phases, where the first phase just
calls remap_decl and nothing else on the non-VLAs is to make sure that
if a VLA type or DECL_VALUE_EXPR uses (usually scalar) vars declared in the
same bind block, then those are processed first.
Jakub