public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bill Schmidt <wschmidt@linux.ibm.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com
Subject: Re: [PATCH 3/8] rs6000: Convert <x> built-in constraints to <x,y> form
Date: Mon, 31 Jan 2022 11:21:32 -0600	[thread overview]
Message-ID: <94c9c8b9-bb8c-ffbe-cabd-f85d54b02440@linux.ibm.com> (raw)
In-Reply-To: <20220128232420.GJ614@gate.crashing.org>

On 1/28/22 5:24 PM, Segher Boessenkool wrote:
> On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote:
>> When introducing the new built-in support, I tried to match as many
>> existing error messages as possible.  One common form was "argument X must
>> be a Y-bit unsigned literal".  Another was "argument X must be a literal
>> between X' and  Y', inclusive".  During reviews, Segher requested that I
>> eventually convert all messages of the first form into the second form for
>> consistency.  That's what this patch does, replacing all <x>-form
>> constraints (first form) with <x,y>-form constraints (second form).
> Well, I asked for the error messages to be clearer and more consistent
> like that.  I don't think changing our source code like this is an
> improvement (*we* know what a 5-bit signed number is).  Do you think
> after your patch it is clearer and we will make fewer errors?

No, I don't think the patch is a particular improvement.  It sounds like
I may have misinterpreted what you were looking for here.  Please let me
know what I might do differently.

For example, if we leave the <x> format in place in the source, I could
change the error messages that we produce to calculate the minimum and
maximum allowed values.  Then we'd still have the changes to the test
cases, but fewer changes to the source.  Thoughts?

Thanks,
Bill

>
> Segher

  reply	other threads:[~2022-01-31 17:21 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-28 17:50 [PATCH 0/8] rs6000: Built-in function cleanups and bug fixes Bill Schmidt
2022-01-28 17:50 ` [PATCH 1/8] rs6000: More factoring of overload processing Bill Schmidt
2022-01-28 19:11   ` Segher Boessenkool
2022-01-28 21:19     ` Bill Schmidt
2022-01-28 23:09       ` Segher Boessenkool
2022-02-01 14:49     ` [PATCH v2 " Bill Schmidt
2022-02-01 21:48       ` Segher Boessenkool
2022-02-02 18:46         ` Bill Schmidt
2022-02-03 14:44         ` [PATCH v3 " Bill Schmidt
2022-02-04  1:24           ` Segher Boessenkool
2022-01-28 17:50 ` [PATCH 2/8] rs6000: Don't #ifdef "short" built-in names Bill Schmidt
2022-01-28 20:32   ` Segher Boessenkool
2022-01-28 21:21     ` Bill Schmidt
2022-01-28 17:50 ` [PATCH 3/8] rs6000: Convert <x> built-in constraints to <x,y> form Bill Schmidt
2022-01-28 23:24   ` [PATCH 3/8] rs6000: Convert <x> built-in constraints to <x, y> form Segher Boessenkool
2022-01-31 17:21     ` Bill Schmidt [this message]
2022-01-31 17:28       ` Segher Boessenkool
2022-01-31 17:31         ` [PATCH 3/8] rs6000: Convert <x> built-in constraints to <x,y> form Bill Schmidt
2022-02-01 14:53         ` [PATCH v2 3/8] rs6000: Unify error messages for built-in constant restrictions Bill Schmidt
2022-02-01 22:16           ` Segher Boessenkool
2022-01-28 17:50 ` [PATCH 4/8] rs6000: Consolidate target built-ins code Bill Schmidt
2022-01-31 21:32   ` Segher Boessenkool
2022-01-31 22:01     ` Bill Schmidt
2022-01-31 22:33       ` Segher Boessenkool
2022-01-28 17:50 ` [PATCH 5/8] rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082] Bill Schmidt
2022-02-01 23:01   ` Segher Boessenkool
2022-01-28 17:50 ` [PATCH 6/8] rs6000: Remove -m[no-]fold-gimple flag [PR103686] Bill Schmidt
2022-02-02 23:21   ` Segher Boessenkool
2022-01-28 17:50 ` [PATCH 7/8] rs6000: vec_neg built-ins wrongly require POWER8 Bill Schmidt
2022-02-07 15:48   ` Bill Schmidt
2022-03-30 18:04   ` Segher Boessenkool
2022-01-28 17:50 ` [PATCH 8/8] rs6000: Fix some missing built-in attributes [PR104004] Bill Schmidt
2022-03-15 13:18   ` rs6000 patch ping: " Jakub Jelinek
2022-03-30 12:28     ` rs6000 patch ping^2: " Jakub Jelinek
2022-03-30 23:07     ` rs6000 patch ping: " Segher Boessenkool
2022-03-31 22:17       ` Segher Boessenkool
2022-03-30 17:41   ` will schmidt

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=94c9c8b9-bb8c-ffbe-cabd-f85d54b02440@linux.ibm.com \
    --to=wschmidt@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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 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).