From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moene.org (84-86-97-173.fixed.kpn.net [84.86.97.173]) by sourceware.org (Postfix) with ESMTPS id 7CFEB3858C66 for ; Tue, 26 Sep 2023 18:40:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CFEB3858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=moene.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=moene.org Received: from localhost ([127.0.0.1]) by moene.org with esmtp (Exim 4.96) (envelope-from ) id 1qlCyr-001YP1-0D for gcc@gcc.gnu.org; Tue, 26 Sep 2023 20:40:20 +0200 Message-ID: <87d8389c-3ff5-45ed-bc5e-19463564d703@moene.org> Date: Tue, 26 Sep 2023 20:40:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Complex numbers support: discussions summary To: gcc@gcc.gnu.org References: Content-Language: en-US From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,KHOP_HELO_FCRDNS,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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 9/26/23 09:30, Richard Biener via Gcc wrote: > On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc wrote: >> As I said at the end of the presentation, we have written a paper which >> explains >> our implementation in details. You can find it on the wiki page of the >> Cauldron >> (https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf). > > Thanks for the detailed presentation at the Cauldron. > > My personal summary is that I'm less convinced delaying lowering is > the way to go. Thanks Sylvain for the quick summary of the discussion - it helps a great deal now that the discussion is still fresh in our memory. Some thought I came up with (of course, only after the end of the conference): In what way is the handling of the complex type different from that of the 128 bit real (i.e., float) type ? Both are not implemented on most architectures; on most they require two registers (or possibly two memory location that do not necessarily have to be adjacent) to be implemented. Yet both are supported by the middle end - consider the clear equivalence of the handling of variables a and b when looking at the result of -fdump-tree-ssa (on x86_64) for: cat 128.f90 parameter (iq=kind(1q0)) real(kind=iq) :: a, b read*, a, b print*, a / b end and: cat complex.f90 complex a,b read*,a,b print*,a/b end Hope this helps for a continuing fruitful discussion. Kind regards, -- Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands