This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: cleanup for conversion exprs code patterns (1/16)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Tomas Bily <tomby at atrey dot karlin dot mff dot cuni dot cz>, gcc-patches at gcc dot gnu dot org, tomby at ucw dot cz, tbily at suse dot cz
- Date: Mon, 31 Mar 2008 20:13:23 +0000 (UTC)
- Subject: Re: [PATCH]: cleanup for conversion exprs code patterns (1/16)
- References: <20080331144912.C402CF00AB@atrey.karlin.mff.cuni.cz> <m363v26c0l.fsf@fleche.redhat.com>
On Mon, 31 Mar 2008, Tom Tromey wrote:
> >>>>> "Tomas" == Tomas Bily <tomby@atrey.karlin.mff.cuni.cz> writes:
>
> Tomas> There is a lot of duplicate code patterns for conversion
> Tomas> expressions (CONVERT_EXPR, NOP_EXPR, NON_LVALUE_EXPR) that can
> Tomas> be substituted by macro.
>
> Did you consider just getting rid of the duplication?
>
> IMO, we only really need CONVERT_EXPR and VIEW_CONVERT_EXPR -- i.e., a
> cast operator and a "change the interpretation" operator. I think all
> the other operations are redundant given that we also carry type
> information. (Well, except NON_LVALUE_EXPR, which should be removed
> but which is a different kind of problem.)
I think of these patches as an intermediate step to removing the
duplication. Once there are no places in the compiler that can receive
both CONVERT_EXPR and NOP_EXPR and treat them differently, we can remove
NOP_EXPR. These patches make it easier to tell when we've reached that
point by massively reducing the number of matches from grep for
CONVERT_EXPR and NOP_EXPR, and they allow gradual incremental improvement
rather than requiring the compiler to be completely frozen for the time
required to audit hundreds of uses, verify none distinguish the two codes,
and prepare, test and have reviewed a patch to remove NOP_EXPR.
Separating mechanical patches like this that should not change compiler
behavior at all from any patches to places where the compiler *does*
distinguish the two tree codes (which need individual analysis) seems a
very good idea to me.
--
Joseph S. Myers
joseph@codesourcery.com