public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Peter Bergner <bergner@linux.ibm.com>,
	Ajit Agarwal <aagarwa1@linux.ibm.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	Richard Biener <richard.guenther@gmail.com>,
	Raphael Zinsly <rzinsly@ventanamicro.com>
Subject: Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.
Date: Sat, 25 Mar 2023 12:09:06 -0600	[thread overview]
Message-ID: <b40a1c1b-b578-9ece-9131-34f0eb4e92f2@gmail.com> (raw)
In-Reply-To: <0caf5e53-76e2-afc6-8b8c-363e56cd8212@linux.ibm.com>



On 3/24/23 15:34, Peter Bergner wrote:
> On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
>>>>> Is there a reason why REE cannot see that our (reg:QI 4) is a param register
>>>>> and thus due to our ABI, already correctly sign/zero extended?
>>>>
>>>> I don't think REE has ever considered exploiting ABI constraints. Handling
>>>> that might be a notable improvement on various targets.  It'd be a great
>>>> place to do some experimentation.
>>>
>>> Ok, so sounds like a good follow-on project after this patch is reviewed
>>> and committed (stage1).  Thanks for your input!
>>
>> Agreed.  I suspect that risc-v will benefit from such work as well.
>> With that in mind, if y'all start poking at this, please loop in Raphael
>> (on cc) who's expressed an interest in this space.
> 
> Will do.  I suspect that it'll be best to come up with some generic interface
> using target hooks like "param regs are sign/zero extended" or "call return
> values are sign/zero extended", etc. that targets can conditionally opt into
> depending on their ABI that is in effect.
I wonder if we already have some of this in place via the ABI 
interfaces.  Or if the ABI interfaces could be slightly revamped to 
utilize the same information as REE.  That way there's a single source 
of truth for this aspect of the ABI.

But we can cross that bridge when we start poking around.

jeff

  reply	other threads:[~2023-03-25 18:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 10:38 Ajit Agarwal
2023-03-23 12:38 ` Peter Bergner
2023-03-23 15:32   ` Ajit Agarwal
2023-03-23 15:32   ` Ajit Agarwal
2023-03-23 16:29     ` Peter Bergner
2023-03-23 16:32       ` Jeff Law
2023-03-23 16:53         ` Peter Bergner
2023-03-23 23:12           ` Jeff Law
2023-03-24 21:34             ` Peter Bergner
2023-03-25 18:09               ` Jeff Law [this message]
2023-03-31  0:01               ` Hans-Peter Nilsson
2023-03-31 14:01                 ` Jeff Law
2023-03-23 13:47 ` Jeff Law
2023-03-23 15:36   ` Ajit Agarwal

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=b40a1c1b-b578-9ece-9131-34f0eb4e92f2@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=aagarwa1@linux.ibm.com \
    --cc=bergner@linux.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    --cc=rzinsly@ventanamicro.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).