From: Umesh Kalappa <umesh.kalappa0@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org,
Andrew Pinski <pinskia@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
Paul E Murphy <murphyp@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: Passing the complex args in the GPR's
Date: Tue, 6 Jun 2023 22:37:19 +0530 [thread overview]
Message-ID: <CAGfacvQ7qE4S-U=XLVRdZmitWJiCcppWH+VscpKz4piDYWwp=w@mail.gmail.com> (raw)
In-Reply-To: <20230606164256.GQ19790@gate.crashing.org>
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 ?
Thank you
~Umesh
On Tue, Jun 6, 2023 at 10:16 PM Segher Boessenkool
<segher@kernel.crashing.org> 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
next prev parent reply other threads:[~2023-06-06 20:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 9:38 [PATCH Linux] powerpc: add documentation for HWCAPs Nicholas Piggin
2022-05-24 9:52 ` Florian Weimer
2022-05-24 18:32 ` Segher Boessenkool
2022-07-15 1:17 ` Nicholas Piggin
2022-07-15 14:35 ` Segher Boessenkool
2022-05-24 17:38 ` Segher Boessenkool
2022-07-15 1:00 ` Nicholas Piggin
2023-06-06 14:49 ` Passing the complex args in the GPR's Umesh Kalappa
2023-06-06 14:58 ` Andrew Pinski
2023-06-06 15:05 ` Umesh Kalappa
2023-06-06 15:16 ` Andrew Pinski
2023-06-06 16:42 ` Segher Boessenkool
2023-06-06 17:07 ` Umesh Kalappa [this message]
2023-06-06 17:33 ` David Edelsohn
2023-06-07 13:17 ` Michael Matz
2023-06-06 17:18 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGfacvQ7qE4S-U=XLVRdZmitWJiCcppWH+VscpKz4piDYWwp=w@mail.gmail.com' \
--to=umesh.kalappa0@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=murphyp@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=pinskia@gmail.com \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.