public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Peter Bergner <bergner@linux.ibm.com>
To: P Jeevitha <jeevitha@linux.vnet.ibm.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	"Kewen.Lin" <linkw@linux.ibm.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH V2] rs6000: Change GPR2 to volatile & non-fixed register for function that does not use TOC [PR110320]
Date: Thu, 14 Dec 2023 21:57:57 -0600	[thread overview]
Message-ID: <31c8427b-4c43-49cd-8187-45a9dd876cfa@linux.ibm.com> (raw)
In-Reply-To: <bbc59eb5-eaff-cb23-328e-2bfff6fcccc6@linux.vnet.ibm.com>

On 7/16/23 10:40 PM, P Jeevitha via Gcc-patches wrote:
> Normally, GPR2 is the TOC pointer and is defined as a fixed and non-volatile
> register. However, it can be used as volatile for PCREL addressing. Therefore,
> modified r2 to be non-fixed in FIXED_REGISTERS and set it to fixed if it is not
> PCREL and also when the user explicitly requests TOC or fixed. If the register
> r2 is fixed, it is made as non-volatile. Changes in register preservation roles
> can be accomplished with the help of available target hooks
> (TARGET_CONDITIONAL_REGISTER_USAGE).
> 
> 2023-07-12  Jeevitha Palanisamy  <jeevitha@linux.ibm.com>
> 
> gcc/
> 	PR target/PR110320
> 	* config/rs6000/rs6000.cc (rs6000_conditional_register_usage): Change
> 	GPR2 to volatile and non-fixed register for PCREL.
> 
> gcc/testsuite/
> 	PR target/PR110320
> 	* gcc.target/powerpc/pr110320-1.c: New testcase.
> 	* gcc.target/powerpc/pr110320-2.c: New testcase.
> 	* gcc.target/powerpc/pr110320-3.c: New testcase.
> 
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index 44b448d2ba6..9aa04ec5d57 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -10193,9 +10193,13 @@ rs6000_conditional_register_usage (void)
>      for (i = 32; i < 64; i++)
>        fixed_regs[i] = call_used_regs[i] = 1;
>  
> +  /* For non PC-relative code, GPR2 is unavailable for register allocation.  */
> +  if (FIXED_R2 && !rs6000_pcrel_p ())
> +    fixed_regs[2] = 1;
> +
>    /* The TOC register is not killed across calls in a way that is
>       visible to the compiler.  */
> -  if (DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)
> +  if (fixed_regs[2] && (DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2))
>      call_used_regs[2] = 0;

Segher and Ke Wen,

As we discussed on my PR111045 patch that disabled PCREL on everything other
than ELFv2 and Segher said, well, it should work on ELFv1, modulo fixing bugs.
Segher said we should attempt to fix those bugs before we ship the next release
and if we miss that, we can push my PR111045 patch then to disable it.

On a related note, Jeevitha's patch above allows using r2 for normal register
allocation if r2 is not fixed and pcrel is enabled.  Given pcrel with this patch
enables pcrel on ELFv1, that means this patch can also enable using r2 for normal
register allocation on ELFv1.  Is that safe?  Should we add a check above where
we set fixed_regs[2] = 1, to also check for whether this is not an ELFv2 compile?
...or Segher, should we leave this as is and add it to the things to check for
non-ELFv2 compiles before the next release and possible disable it then if we
know/aren't sure whether it legal?

So I guessing I'm wondering, should Jeevitha push the above approved patch as
is, or should we modify it so r2 is only available for RA on ELFv2 and pcrel?

Peter



  parent reply	other threads:[~2023-12-15  3:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <99f9935c-5430-dcd7-1235-ccad50fb6122@linux.vnet.ibm.com>
2023-07-17  3:40 ` P Jeevitha
2023-07-19  6:43   ` Kewen.Lin
2023-12-15  3:57   ` Peter Bergner [this message]
2023-12-15  4:29     ` 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=31c8427b-4c43-49cd-8187-45a9dd876cfa@linux.ibm.com \
    --to=bergner@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeevitha@linux.vnet.ibm.com \
    --cc=linkw@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).