public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches@gcc.gnu.org, "Kewen.Lin" <linkw@linux.ibm.com>,
	David Edelsohn <dje.gcc@gmail.com>,
	Peter Bergner <bergner@linux.ibm.com>,
	Will Schmidt <will_schmidt@vnet.ibm.com>
Subject: Re: [PATCH] Improve converting between 128-bit modes that use the same format
Date: Wed, 7 Sep 2022 15:56:21 -0500	[thread overview]
Message-ID: <20220907205621.GL25951@gate.crashing.org> (raw)
In-Reply-To: <Yxj+TbDraRVsOUFe@toto.the-meissners.org>

On Wed, Sep 07, 2022 at 04:25:49PM -0400, Michael Meissner wrote:
> On Tue, Sep 06, 2022 at 05:22:11PM -0500, Segher Boessenkool wrote:
> > Please do this.  It is the biggest problem I have with most of your
> > patches: you seem to save up development of a week, and then send it out
> > as big omnibus patch an hour or two before my weekend.  This is not
> > ideal.
> 
> This is always going to be the case.  As I'm developing the larger patches,
> there are usually at least 3 smaller problems wanting to get out.  I don't know
> what these things are until I run into them.

This is the only large problem.  Humongous, if you want.  It has been
_the_ problem since the beginning of the IEEE QP work.  None of this is
news to anyone.

It makes all other problems tens of times as hard to solve.

The other thing that would have made development way way way less work
in total, and much simpler, is supporting this on more systems.
Everything with VMX for example (with the exact same ABI as we have
now!), or just a la "nof" ("-msoft-float"), which is easy to so as well.
You end up testing more cases, "having" to test more cases, *but* there
are way fewer exceptions.  Anything downstream from us (essentially
everything, we are the C and C++ compilers after all) has to do a lot
of unnecessary work as well, because of this.

But the fundamental problem that IEEE QP and double-double can not be
ordered causes so many problems it is just not funny.  The *workarounds*
for it each cause a cascade of *other problems*, and there is no end in
sight.


Segher

  reply	other threads:[~2022-09-07 20:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-18 21:48 Michael Meissner
2022-08-23 21:13 ` Segher Boessenkool
2022-09-02 17:51   ` Michael Meissner
2022-09-06 22:22     ` Segher Boessenkool
2022-09-07 20:25       ` Michael Meissner
2022-09-07 20:56         ` Segher Boessenkool [this message]
2022-09-12 19:28 ` Michael Meissner

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=20220907205621.GL25951@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=bergner@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@linux.ibm.com \
    --cc=meissner@linux.ibm.com \
    --cc=will_schmidt@vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).