[PATCH] New predicate covering NOP_EXPR and CONVERT_EXPR

Joseph S. Myers joseph@codesourcery.com
Fri Dec 2 16:38:00 GMT 2005


On Fri, 2 Dec 2005, Giovanni Bajo wrote:

> Given that, in tree-ssa times, *most* of the compiler does not know the
> difference between NOP_EXPR and CONVERT_EXPR and the exact semantics are
> gone, I think such an audit will be a waste of time, and in practice nobody
> will ever do it and we'll have to live with those duplicate trees for more
> time.

I don't believe that "most".  There are lots of distinctions, some 
intentional and some not.

It's simply a matter of due diligence to read and understand the code you 
are changing (directly or by implication by changing the semantics of 
internal representation - in which I include clarifying unclear 
semantics).

Every piece of code referencing NOP_EXPR and CONVERT_EXPR together needs 
to change anyway to reference just one; I don't see a problem with 
changing such pieces of code twice.  This is a purely mechanical change or 
pair of changes in any case.

I contend that every piece of code distinguishing NOP_EXPR and 
CONVERT_EXPR must be examined manually, any intended distinction 
identified, and a patch posted to gcc-patches to fix the code not to 
distinguish based on the tree code, with the rationale including the 
analysis of what if anything the code is trying to distinguish.  It 
doesn't matter whether this is done through seeing what's left after 
moving to NOP_CONVERSION_P, or by checking all 600 references to one or 
the other to identify those which distinguish them, though the first may 
be more reliable since otherwise you need to check all commits going in 
between when you check the 600 references and when you commit the 
unification.  But this should be done separately from actually unifying 
the codes.

> We can pretty much go the other way: fix the 3-4 places left which don't
> treat them the same way with Roger's approach, and find out what breaks (if
> anything). Given that Roger can bootstrap/regtest C and C++ with no

Finding out what breaks requires a manual examination, with explanation 
posted to gcc-patches, of all references which distinguish the codes.  
The testsuite coverage is far too incomplete to pretend that not 
regressing in the testsuite can substitute for such an analysis.

There are only 627 references to NOP_EXPR or CONVERT_EXPR in *.[ch] 
*/*.[ch] config/*/*.[ch] (a few are false positives, being references to 
VIEW_CONVERT_EXPR, and various others are creating the tree codes rather 
than using them).  Most of them in fact treat the two cases the same, 
identifying and analysing the remainder is perfectly feasible.

-- 
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 Java-patches mailing list