* NOP_EXPR vs. CONVERT_EXPR
@ 2023-12-05 14:52 Alexander Monakov
2023-12-05 14:53 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: Alexander Monakov @ 2023-12-05 14:52 UTC (permalink / raw)
To: gcc
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?
Thanks.
Alexander
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: NOP_EXPR vs. CONVERT_EXPR
2023-12-05 14:52 NOP_EXPR vs. CONVERT_EXPR Alexander Monakov
@ 2023-12-05 14:53 ` Richard Biener
2023-12-08 0:24 ` Jeff Law
0 siblings, 1 reply; 4+ messages in thread
From: Richard Biener @ 2023-12-05 14:53 UTC (permalink / raw)
To: Alexander Monakov; +Cc: gcc
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.
Richard.
>
> Thanks.
> Alexander
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: NOP_EXPR vs. CONVERT_EXPR
2023-12-05 14:53 ` Richard Biener
@ 2023-12-08 0:24 ` Jeff Law
2023-12-08 6:51 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: Jeff Law @ 2023-12-08 0:24 UTC (permalink / raw)
To: Richard Biener, Alexander Monakov; +Cc: gcc
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: NOP_EXPR vs. CONVERT_EXPR
2023-12-08 0:24 ` Jeff Law
@ 2023-12-08 6:51 ` Richard Biener
0 siblings, 0 replies; 4+ messages in thread
From: Richard Biener @ 2023-12-08 6:51 UTC (permalink / raw)
To: Jeff Law; +Cc: Alexander Monakov, gcc
On Fri, Dec 8, 2023 at 1:24 AM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> 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.
It's not so long that I tried this (but really by removing NOP_EXPR) when
I figured the C++ FE at least won't be happy. The gimplification route
and IL checking so NOP_EXPR doesn't creep back in could work though.
Richard.
> jeff
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-12-08 6:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-05 14:52 NOP_EXPR vs. CONVERT_EXPR Alexander Monakov
2023-12-05 14:53 ` Richard Biener
2023-12-08 0:24 ` Jeff Law
2023-12-08 6:51 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).