Re: NOP_EXPR vs. CONVERT_EXPR

[Jeff Law <jeffreyalaw@gmail.com>]

On 12/5/23 07:53, Richard Biener via Gcc wrote:
> On Tue, Dec 5, 2023 at 3:54 PM Alexander Monakov via Gcc
> <gcc@gcc.gnu.org> wrote:
>>
>> Greetings,
>>
>> the definitions for NOP_EXPR and CONVERT_EXPR in tree.def, having survived
>> all the way from 1992, currently say:
>>
>>      /* Represents a conversion of type of a value.
>>         All conversions, including implicit ones, must be
>>         represented by CONVERT_EXPR or NOP_EXPR nodes.  */
>>      DEFTREECODE (CONVERT_EXPR, "convert_expr", tcc_unary, 1)
>>
>>      /* Represents a conversion expected to require no code to be generated.  */
>>      DEFTREECODE (NOP_EXPR, "nop_expr", tcc_unary, 1)
>>
>> Unfortunately, they are confusing, as in
>>
>>      float f(double d)
>>      {
>>          return d;
>>      }
>>
>> the narrowing conversion is represented with NOP_EXPR, and it is definitely
>> not a no-op.
>>
>> Does some clear distinction remain, and is it possible to clarify the
>> definitions?
> 
> {NOP,CONVERT}_EXPR are interchangeable in the middle-end but
> frontends (IIRC the C++ FE mainly) distinguishes them.  So a uniform
> documentation might be difficult - in the end we could eventually
> drop NOP_EXPR from the middle-end (during gimplification?) and
> only use CONVERT_EXPR.  All uses should use CASE_CONVERT
> or CONVERT_EXPR_CODE_P which globs both.
I thought someone looked at this a while ago (measured in years) and 
concluded it wasn't actually feasible.  Perhaps because the middle end 
still hands things off to routines that are also used by the FE.

I could see dropping/converting during gimplification with a checker 
that verifies they don't sneak back in.  Then we can start to expunge 
them from gimple passes.  Feels like a gcc-15+ problem to me.

jeff