This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: cleanup for conversion exprs code patterns (1/16)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]