From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id CDAED384D1BC for ; Fri, 24 Jun 2022 21:54:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CDAED384D1BC Received: by mail-pf1-x429.google.com with SMTP id w6so3642923pfw.5 for ; Fri, 24 Jun 2022 14:54:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=KKCjzBr4lLFu1xLryJuRwOZwkgZUaMUJyoVzf7ZMQSM=; b=QeFBde/RJfSZOVbIxE0OTjNJadZ/cBZphor7TtOGu96KeDhWYTWJ3QreGRammdLbex eoMY27Th1Etpb83IsiyAjKBom7hXZP4CqxbxNOaY/2UDAUv6HMi8q/R+isu3GQJp/Dmn vBknrGomJ9fDGdWG2pKFU83Q5GCcKZ81509tg0OWaNTP9YjhTI+S6jNSSepGuO7jVp7Q kQCUT0GHGLqytBZxvIXDl8ViIdnz1zJF7plgP/lZLmLtsYxamg55UX2Mghmji/wXdkWD PmJFKCa/gBPnPzX0Ud3Om8LxhhQ7mphQrzfU+hCVGM3WeKw6BCtTbzL0wazp7ua85Szw U6tg== X-Gm-Message-State: AJIora/KZldxqKHEjgKGDZuw8dKXcGD4JjzzBiQGciFaXhXD0aLseBq1 hhPXj66MiCs/ff148MAJbVLLTx6JpjI= X-Google-Smtp-Source: AGRyM1stq7jbxMqHFzzOOJ/tQRs/jWR0WIgR4W30lpPOzZ9X5EVsCxloK8EaoRksZrcDrPB1MEJz6A== X-Received: by 2002:a05:6a00:3210:b0:524:c5c2:bec1 with SMTP id bm16-20020a056a00321000b00524c5c2bec1mr1231875pfb.29.1656107650535; Fri, 24 Jun 2022 14:54:10 -0700 (PDT) Received: from [172.31.0.204] (c-73-63-24-84.hsd1.ut.comcast.net. [73.63.24.84]) by smtp.gmail.com with ESMTPSA id cp2-20020a170902e78200b0015e8d4eb1d7sm2292194plb.33.2022.06.24.14.54.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jun 2022 14:54:10 -0700 (PDT) Message-ID: Date: Fri, 24 Jun 2022 15:54:09 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to set the lowpart. Content-Language: en-US To: Jeff Law via Gcc-patches , Richard Biener , richard.sandiford@arm.com References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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: Fri, 24 Jun 2022 21:54:13 -0000 On 6/15/2022 5:36 AM, Richard Sandiford wrote: > Jeff Law via Gcc-patches writes: >> On 6/13/2022 5:54 AM, Richard Biener wrote: >>> 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. >> I don't see any reasonable way to do that.  Without going into all the >> details, our complex ops work on low elements within a vector >> register.   Trying to recover them after gimple->rtl expansion would be >> similar to trying to SLP vectorize on RTL, something I'm not keen to chase. >> >> It would be a hell of a lot easier to leave the complex ops as complex >> ops to the expanders, then make the decision to use the complex >> instructions or decompose into components. > Realise you might not be in a position to answer this for confidentiality > reasons, but: would normal tree SLP not help here? We already try to > recognise complex add & multiply, and in principle we could do the same > for other operations as well. It shouldn't matter that a vector > multiply on 2 elements is really just a single-data operation. That's the only viable option I see for our target if we keep the model where complex operations are broken down into their component operations in the gimple passes. jeff