From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by sourceware.org (Postfix) with ESMTPS id 0D8313858CD1 for ; Fri, 8 Dec 2023 06:51:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0D8313858CD1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0D8313858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702018301; cv=none; b=LawqX8UbgtpPCse9Y+FwOKkeuvYV6CiQN6UyT+UikaDweVPVOpuTt7Y2KdOOrwKtxVLyBvQofze9Bg5Z/1nYs9IXiAM0FiquPCpGggrjWWhtifJY5FZGgm8NAw9AYzPv2lFdewOMQz53csCLpMrj0iCYJ098fDG1JpYTtrFWNuw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702018301; c=relaxed/simple; bh=cRtlqqJIcW9p6HNsgc+fiLv96jXq1qsKhQtqZQCnKU0=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=XUUsXBfRAMt77pQ+RRJum1c4zq8hxjr1WND01sC9E6L4lVutHJlkuyjfUyOJLkRdTQOVTsGyGHRDBTNsCp9/H9hdiiJhTJOxPNEaHp9zXH7mRSiCpfpYjvKvC7pUIW/GEXx7SnrGmkDyFvxx65q4NGUwbD61iB9jYKW/B+zEN0c= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-50be10acaf9so1624976e87.1 for ; Thu, 07 Dec 2023 22:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702018298; x=1702623098; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GTnuHlKIiVBiKvLgF+OGeedJoYu9oZ9TULVNYCxb6LI=; b=gZQvptS4wuL3r787dQ+F3f25NtaZTvvPIUNm8ik95Y7PcX/TKfno18yQDtwgBxMl9+ DB39BtJ3rCHSuJigA9wXqO/lF7ANj5VJoNoIHgsCrDuSQ4eLHpLR5WXl/bUWDLYcVOj5 IzspWiIL9zzuDBzlkkC67Dd1HqUMcQgHIXmMvkBKVMRTlwRBg7Q0023eWpInlBrtzn9e cxGapi/W8vfJ1FcQNnV2ozRz94QKAci8LpZ8q9x8pZoH2hh5XLxULn0QP5Wkq5CMEd0x BEsyohF1hQOyebbqJYmIvFwCkjIrHWFW2ptI7lQqpV+zPrukqgFPyThwklh423jZs3Hl lWeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702018298; x=1702623098; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GTnuHlKIiVBiKvLgF+OGeedJoYu9oZ9TULVNYCxb6LI=; b=sL7/kFRRGZ6nHIxjk9lDmAb9yRgpwXbPzYr1aEyg+JutlyxQ5d/haY/NY5SMlnpW4K 3qwivIjJ2kd0zP6uVHryAbno/2RXsQOBnyajxELDwInjn5LdSpUNeQYeeUpZe40y2tWa CkxhbN3fUE6HNpA5+A2byvEpFbTOgtZah9XdHh13R9Kl4N+asoi98jFYmA8efy3cLDCY U/sJpdPlfKX55K9T8reQkzSRFSxC776rI54igH5vUUL22zPXuNzmhjKBZWEAgElQR+cf q/kCENLJd9EKWVz0iXjo+Jma39jYAGnn4ZBOLejCndtuG84JcHfgSu4L30sqf9BsPmYa oiYw== X-Gm-Message-State: AOJu0Yz6Fc8ieldUorW3Va2maYVrGWBjB2lzXx0dBQIA8WAmc8gA67GO McNKhXG42FAZTIrux9CLMVoE/r1GD7O1U9/bj5xDP/8R X-Google-Smtp-Source: AGHT+IGHsAVa7kIFsKeCiE64ylvqB7saN1FurnYIq71CXX5L1eLJB/d7uUONZ6k8HaHno+B5psuKvDsyb597AjZC86U= X-Received: by 2002:ac2:4e43:0:b0:50b:fd3c:5dab with SMTP id f3-20020ac24e43000000b0050bfd3c5dabmr194362lfr.27.1702018298297; Thu, 07 Dec 2023 22:51:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 8 Dec 2023 07:51:26 +0100 Message-ID: Subject: Re: NOP_EXPR vs. CONVERT_EXPR To: Jeff Law Cc: Alexander Monakov , gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Dec 8, 2023 at 1:24=E2=80=AFAM Jeff Law wro= te: > > > > On 12/5/23 07:53, Richard Biener via Gcc wrote: > > On Tue, Dec 5, 2023 at 3:54=E2=80=AFPM Alexander Monakov via Gcc > > wrote: > >> > >> Greetings, > >> > >> the definitions for NOP_EXPR and CONVERT_EXPR in tree.def, having surv= ived > >> 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 gene= rated. */ > >> 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 defin= itely > >> 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