From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id D5E4B3858D38 for ; Tue, 6 Jun 2023 17:33:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D5E4B3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-977d4a1cf0eso424355366b.1 for ; Tue, 06 Jun 2023 10:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686072823; x=1688664823; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6GEO8lpvX/2tJUWSIe8jA/199X71Q33YZFyKiSiCM9U=; b=X3+kl1sTvnPHLjZNMU4XVJfob3un7xQfeBw5gHTPfHrw0WXO5dgCUJwTRc85o3rV1k UAraCR4wbQWakJSa6NtXQD5fnTfPJRCSmBwDH6F7UtQY1vei167xjBkfGr+nKZsqawQv QApxarwU1iUpwlMB+jqY8tZT24Xs7umMChBcb9zBLH67u/kcqfqxL7Qeoh1QRnRxPgxn a1K3C8EIQY5rXU7ZdZ55bGh5IfhLGbP6Hiaj/YgJm2hQgWD4ZtpO2NBc25mLsOl1sfu7 OiqZgifKExjJRg7BO55Gp5AukHtf7CLKtt4Fzt49X5eE5oEZVQ6jkO0bJ+U+wrixs5eW Nzew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686072823; x=1688664823; h=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=6GEO8lpvX/2tJUWSIe8jA/199X71Q33YZFyKiSiCM9U=; b=i50i60aB1DKf+AHlFsxL5QN4Te+i4Jn2M1NwuwY7dq2zHgsnbw34Vzp42Z1Gc06cfa KYVkAzCS+XbAmwwyAPC7c9z/KnH+HdUFEwH16mUqwJAyvoI3U74V0JBOBejrzIJ0a0x0 fZpfsCjP3AAYznGKV3IbSNRhosjHGT0EIRO3L3U34oJDQtwu+GzmPSqH7WhRhyiQTkj8 YGAI6EOYmYxojKTF3v1Uumw8VyKlb2jk87/FA7HycF58zV1DKTZqcQlWiBHmlvuSnteH 8TRIoP9Mon3zry1DESyHmOo/UaQGjHgXQ1fZZsBf3/k68OohGQUisQb+rtyJdlbHCIzb AGOQ== X-Gm-Message-State: AC+VfDzhTMubHMWCkIC/jRLA5p5K0ebT5A/tGhveOkLFw+BDAQuLhq5v n4xSPndzq4jgzCk+R2dXsu2h4dRxh3qzdOO3R5o= X-Google-Smtp-Source: ACHHUZ6Sxgfj5Ayc8TElxXq41LxV1S3Tx2UHcj8M215oC6rvgx3sj4Pe/8TRYOJsB6vyR4dzaeKSV0+DQ9X2bbuortQ= X-Received: by 2002:a17:907:2da9:b0:96a:4f89:3916 with SMTP id gt41-20020a1709072da900b0096a4f893916mr2743992ejc.58.1686072823366; Tue, 06 Jun 2023 10:33:43 -0700 (PDT) MIME-Version: 1.0 References: <20220524093828.505575-1-npiggin@gmail.com> <20230606164256.GQ19790@gate.crashing.org> In-Reply-To: From: David Edelsohn Date: Tue, 6 Jun 2023 13:33:30 -0400 Message-ID: Subject: Re: Passing the complex args in the GPR's To: Umesh Kalappa Cc: Segher Boessenkool , Andrew Pinski , Nicholas Piggin , linuxppc-dev@lists.ozlabs.org, gcc@gcc.gnu.org, libc-alpha@sourceware.org, Michael Ellerman , Paul E Murphy Content-Type: multipart/alternative; boundary="000000000000b3ca5505fd796bc4" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,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: --000000000000b3ca5505fd796bc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 6, 2023 at 1:08=E2=80=AFPM Umesh Kalappa via Gcc wrote: > Hi Segher , > > >>What did you expect, what happened instead? > For example the complex args are passed in GPR's for cexp in the case > GCC and Clang uses caller memory . > > for reference : https://godbolt.org/z/MfMz3cTe7 > > We have cross tools like some of libraries built using the GCC and > some use Clang . > > We approached Clang developers on this behaviour (Why stack , not the > FPR's registers like PPC64) and they are not going to change this > behaviour, and asked us to refer back to GCC ,hence this email thread. > > Question is : Why does GCC choose to use GPR's here and have any > reference to support this decision ? > The use of GPRs to pass complex floating point arguments was an early implementation mistake -- the parameter passing code missed the enumeration of a type. The behavior cannot be changed and corrected without breaking the ABI. I don't know what you mean by "support this decision". It was not intentionally chosen through careful performance analysis or type system design as the preferred method to pass complex floating point values. The initial implementation was wrong and not discovered until it was too late. The reference to support this is that one cannot break the ABI without causing chaos in the ecosystem. Thanks, David > > Thank you > ~Umesh > > > > On Tue, Jun 6, 2023 at 10:16=E2=80=AFPM Segher Boessenkool > wrote: > > > > Hi! > > > > On Tue, Jun 06, 2023 at 08:35:22PM +0530, Umesh Kalappa wrote: > > > Hi Adnrew, > > > Thank you for the quick response and for PPC64 too ,we do have > > > mismatches in ABI b/w complex operations like > > > https://godbolt.org/z/bjsYovx4c . > > > > > > Any reason why GCC chose to use GPR 's here ? > > > > What did you expect, what happened instead? Why did you expect that, > > and why then is it an error what did happen? > > > > You used -O0. As long as the code works, all is fine. But unoptimised > > code frequently is hard to read, please use -O2 instead? > > > > As Andrew says, why did you use -m32 for GCC but -m64 for LLVM? It is > > hard to compare those at all! 32-bit PowerPC Linux ABI (based on 32-bit > > PowerPC ELF ABI from 1995, BE version) vs. 64-bit ELFv2 ABI from 2015 > > (LE version). > > > > > > Segher > --000000000000b3ca5505fd796bc4--