public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Peter Bergner <bergner@linux.ibm.com>
To: Michael Meissner <meissner@linux.ibm.com>,
	"Kewen.Lin" <linkw@linux.ibm.com>
Cc: P Jeevitha <jeevitha@linux.ibm.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Segher Boessenkool <segher@kernel.crashing.org>
Subject: Re: [PATCH] rs6000: Fix issue in specifying PTImode as an attribute [PR106895]
Date: Thu, 24 Aug 2023 21:19:51 -0500	[thread overview]
Message-ID: <9a300552-21a6-cc4c-294d-bec0c6b3739c@linux.ibm.com> (raw)
In-Reply-To: <ZOeU0TYMPgAf4PFQ@cowardly-lion.the-meissners.org>

On 8/24/23 12:35 PM, Michael Meissner wrote:
> On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
>> gcc/
>> 	PR target/110411
>> 	* config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
>> 	to hold PTImode type.
>> 	* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Add node
>> 	for PTImode type.
> 
> It is good as far as it goes, but I suspect we will eventually need to extend
> it.  In particular, the reason people need PTImode is they need the even/odd
> register layout.  What you've done enables users to declare this value.

Sure, it could be extended, but that is not what this patch is about.
It's purely to allow the kernel team access to the guaranteed even/odd
register layout for some inline asm code.  Any extension would be a
follow-on patch to this.



On 8/9/23 3:48 AM, Kewen.Lin wrote:
> IIUC, this builtin type registering makes this type expose to users, so
> I wonder if we want to actually expose this type for users' uses.
> If yes, we need to update the documentation (and not sure if the current
> name is good enough); otherwise, I wonder if there is some existing
> practice to declare a builtin type with a name which users can't actually
> use and is just for shadowing a mode.

Segher, Mike, Jeevitha and I talked about the patch and Segher mentioned
that under some conditions, it's fine to keep the type undocumented.
Hopefully he'll weigh in on whether this particular patch is one of
those cases or not.  


Peter

  reply	other threads:[~2023-08-25  2:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-20  4:35 jeevitha
2023-08-04 10:12 ` [PING ^1][PATCH] " jeevitha
2023-08-09  8:48 ` [PATCH] " Kewen.Lin
2023-08-24 17:35 ` Michael Meissner
2023-08-25  2:19   ` Peter Bergner [this message]
2023-08-26  8:37     ` Michael Meissner
2023-11-13 15:08     ` [PING ^1][PATCH] " jeevitha
2023-12-11 19:11       ` [PING ^3][PATCH] " jeevitha
     [not found] <9ea38d87-180f-46b5-a723-45061680980f@linux.vnet.ibm.com>
2024-02-23  9:34 ` [PATCH] " jeevitha
2024-03-18 14:36   ` Segher Boessenkool
2024-03-18 17:35     ` Peter Bergner

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=9a300552-21a6-cc4c-294d-bec0c6b3739c@linux.ibm.com \
    --to=bergner@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeevitha@linux.ibm.com \
    --cc=linkw@linux.ibm.com \
    --cc=meissner@linux.ibm.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 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).