From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) by sourceware.org (Postfix) with ESMTPS id 8BCB038387E1 for ; Mon, 13 Jun 2022 11:54:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BCB038387E1 Received: by mail-qv1-xf2c.google.com with SMTP id a9so4144628qvt.6 for ; Mon, 13 Jun 2022 04:54:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=McxmeWmCYJQ91m5C6d+RCUZ1+FpH1E+l14gjEfItM+8=; b=H0LP/ae2OevZC3XNHHM+ZowpvQCtrru/WviTl9tIeu7cFqYVZGAqZtfX8kODADaYG2 Mg2WkJLAwtZczUAUtTKEk0gw+GTEZBU9RdB9DZwmcqGuvxtvg16plQidMj1vkoKcObib dlODc9nlbYYPSp61t2Qt3YOLJdwSy+a8VaIH0DKKdXQf3PoZb5DrfBwqA6b2bK+cthbB mjsnaX8ESRdrrsBqNj4mnRU81bftKxsKi+WNp7P38aAbe/6bSV8llgqHiqeRiTHvp6Qy IsGBfdqv+mpm3S57dVvNMsF5/V+9GRhI0cvsvPFXwo0DBJTDoUcLQTmxbzUOSd2CP5iX jsfA== X-Gm-Message-State: AOAM530X+gPryEiW/j1wdxbKStPd0eKJRGEQrgXOHwrBgZ88zpWGZUsx uCxwfZkDAKT+rEp8vDYZFKaYMWD4QdVAttpu2XSnlCNdXKU= X-Google-Smtp-Source: ABdhPJxyZsXGXOgj9g0/le6py+QHJysdpydbPZ/WWwIsGhDHQPrpoaNIf8bTYklWNIYXxx/jMhyI8KbkAGqMHB7WrgU= X-Received: by 2002:a05:6214:21cf:b0:462:485b:d7b9 with SMTP id d15-20020a05621421cf00b00462485bd7b9mr82770460qvh.78.1655121295851; Mon, 13 Jun 2022 04:54:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Mon, 13 Jun 2022 13:54:44 +0200 Message-ID: Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to set the lowpart. To: Jeff Law Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.1 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2022 11:54:58 -0000 On Sun, Jun 12, 2022 at 7:27 PM Jeff Law via Gcc-patches wrote: [...] > On a related topic, any thoughts on keeping complex objects as complex > types/modes through gimple and into at least parts of the RTL pipeline? > > The way complex arithmetic instructions work on our chip is going to be > extremely tough to utilize in GCC -- we really need to the complex > types/arithmetic up through RTL generation at the least. Ideally we'd > even expose complex modes all the way to final. Is that something > y'all could benefit from as well? Have y'all poked at this problem at all? Since you are going to need to "recover" complex operations from people open-coding them (both fortran and C and also C++ with std::complex) it should be less work to just do that ;) I think that complex modes and types exist solely for ABI purposes. Richard. > jeff >