[Committed] PR middle-end/19331: Inefficient bitfield assignment

Joseph S. Myers joseph@codesourcery.com
Sun Mar 13 23:01:00 GMT 2005


On Sun, 13 Mar 2005, Roger Sayle wrote:

> For 4.1, I have a plan...  I intend to deprecate NOP_EXPR sometime during
> stage1, by placing "#define NOP_EXPR CONVERT_EXPR" in tree.h, and
> removing the unique tree code for NOP_EXPR from tree.def.  The immediate
> fallout is that any switch statement containing both a CONVERT_EXPR and
> a NOP_EXPR, will need to remove the duplicate.  This will cure this class
> of problem once and for all, and allow a transition series of clean-ups to

Surely an audit is needed first of every place that handles NOP_EXPR 
differently from CONVERT_EXPR to see whether it depends on some property 
which not all CONVERT_EXPRs have?  Given an audit of every reference to 
NOP_EXPR or CONVERT_EXPR that doesn't treat both identically (and fixing 
them all to check for substantive properties of the conversion in question 
instead of distinguishing those tree codes) the change seems a good idea.

For example, c-convert.c has a comment saying:

/* Change of width--truncation and extension of integers or reals--
   is represented with NOP_EXPR.  Proper functioning of many things
   assumes that no other conversions can be NOP_EXPRs.

   Conversion between integer and pointer is represented with CONVERT_EXPR.
   Converting integer to real uses FLOAT_EXPR
   and real to integer uses FIX_TRUNC_EXPR.
   [...]

It is very likely that much of this is out of date, but it illustrates the 
need for a complete audit of the approximately 600 references to NOP_EXPR 
or CONVERT_EXPR, minus those which treat both identically (which I hope 
will be many of them).  It seems likely that the audit process will 
uncover bugs as well as places which are not robust to handling the 
greater range of conversions in the new CONVERT_EXPR.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)



More information about the Gcc-patches mailing list