From: Ajit Agarwal <aagarwa1@linux.ibm.com>
To: rep.dot.nop@gmail.com, gcc-patches@gcc.gnu.org,
Vineet Gupta <vineetg@rivosinc.com>
Cc: Jeff Law <jeffreyalaw@gmail.com>,
Richard Biener <richard.guenther@gmail.com>,
Segher Boessenkool <segher@kernel.crashing.org>,
Peter Bergner <bergner@linux.ibm.com>,
gnu-toolchain <gnu-toolchain@rivosinc.com>
Subject: Re: [PATCH v9 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces
Date: Mon, 23 Oct 2023 12:16:18 +0530 [thread overview]
Message-ID: <fdf4e055-d811-4eae-b83a-100f27dfdb61@linux.ibm.com> (raw)
In-Reply-To: <BE66BD85-6DBE-436B-817A-E633D40C48A3@gmail.com>
Hello All:
Addressed below review comments in the version 11 of the patch.
Please review and please let me know if its ok for trunk.
Thanks & Regards
Ajit
On 22/10/23 12:56 am, rep.dot.nop@gmail.com wrote:
> On 21 October 2023 01:56:16 CEST, Vineet Gupta <vineetg@rivosinc.com> wrote:
>> On 10/19/23 23:50, Ajit Agarwal wrote:
>>> Hello All:
>>>
>>> This version 9 of the patch uses abi interfaces to remove zero and sign extension elimination.
>>> Bootstrapped and regtested on powerpc-linux-gnu.
>>>
>>> In this version (version 9) of the patch following review comments are incorporated.
>>>
>>> a) Removal of hard code zero_extend and sign_extend in abi interfaces.
>>> b) Source and destination with different registers are considered.
>>> c) Further enhancements.
>>> d) Added sign extension elimination using abi interfaces.
>>
>> As has been trend in the past, I don't think all the review comments have been addressed.
>
> And apart from that, may I ask if this is just me, or does anybody else think that it might be worthwhile to actually read a patch before (re-)posting?
>
> Seeing e.g. the proposed abi_extension_candidate_p as written in a first POC would deserve some manual CSE, if nothing more then for clarity and conciseness?
>
> Just curious from a meta perspective..
>
> And:
>
>>> ree: Improve ree pass for rs6000 target using defined abi interfaces
>
> mentioning powerpc like this, and then changing generic code could be interpreted as misleading, IMHO.
>
>>>
>>> For rs6000 target we see redundant zero and sign extension and done
>>> to improve ree pass to eliminate such redundant zero and sign extension
>>> using defined ABI interfaces.
>
> Mentioning powerpc in the body as one of the affected target(s) is of course fine.
>
>
>>> +/* Return TRUE if target mode is equal to source mode of zero_extend
>>> + or sign_extend otherwise false. */
>
> , false otherwise.
>
> But I'm not a native speaker
>
>
>>> +/* Return TRUE if the candidate insn is zero extend and regno is
>>> + a return registers. */
>>> +
>>> +static bool
>>> +abi_extension_candidate_return_reg_p (/*rtx_insn *insn, */int regno)
>
> Leftover debug comment.
>
>>> +{
>>> + if (targetm.calls.function_value_regno_p (regno))
>>> + return true;
>>> +
>>> + return false;
>>> +}
>>> +
>
> As said, I don't see why the below was not cleaned up before the V1 submission.
> Iff it breaks when manually CSEing, I'm curious why?
>
>>> +/* Return TRUE if reg source operand of zero_extend is argument registers
>>> + and not return registers and source and destination operand are same
>>> + and mode of source and destination operand are not same. */
>>> +
>>> +static bool
>>> +abi_extension_candidate_p (rtx_insn *insn)
>>> +{
>>> + rtx set = single_set (insn);
>>> + machine_mode dst_mode = GET_MODE (SET_DEST (set));
>>> + rtx orig_src = XEXP (SET_SRC (set), 0);
>>> +
>>> + if (!FUNCTION_ARG_REGNO_P (REGNO (orig_src))
>>> + || abi_extension_candidate_return_reg_p (/*insn,*/ REGNO (orig_src)))
>
> On top, debug leftover.
>
>>> + return false;
>>> +
>>> + /* Mode of destination and source should be different. */
>>> + if (dst_mode == GET_MODE (orig_src))
>>> + return false;
>>> +
>>> + machine_mode mode = GET_MODE (XEXP (SET_SRC (set), 0));
>>> + bool promote_p = abi_target_promote_function_mode (mode);
>>> +
>>> + /* REGNO of source and destination should be same if not
>>> + promoted. */
>>> + if (!promote_p && REGNO (SET_DEST (set)) != REGNO (orig_src))
>>> + return false;
>>> +
>>> + return true;
>>> +}
>>> +
>
> As said, please also rephrase the above (and everything else if it obviously looks akin the above).
>
> The rest, mentioned below, should largely be covered by following the coding convention.
>
>>> +/* Return TRUE if the candidate insn is zero extend and regno is
>>> + an argument registers. */
>
> Singular register.
>
>>> +
>>> +static bool
>>> +abi_extension_candidate_argno_p (/*rtx_code code, */int regno)
>
> Debug leftover.
> I would probably have inlined this function manually, with a respective comment.
> Did not look how often it is used, admittedly.
>
>>> +{
>>> + if (FUNCTION_ARG_REGNO_P (regno))
>>> + return true;
>>> +
>>> + return false;
>>> +}
> []
>>> +
>>> /* This function goes through all reaching defs of the source
>
> s/This function goes/Go/
>
>>> of the candidate for elimination (CAND) and tries to combine
>
> (of, ?didn't look) candidate CAND for eliminating
>
>>> the extension with the definition instruction. The changes
>
> defining
>
> Pre-existing, I know.
> But you could fix those in a preparatory patch while you touch surrounding code.
> This is not a requirement, of course, just good habit, IMHO.
>
>>> @@ -770,6 +889,11 @@ combine_reaching_defs (ext_cand *cand, const_rtx set_pat, ext_state *state)
>>> state->defs_list.truncate (0);
>>> state->copies_list.truncate (0);
>>> + rtx orig_src = XEXP (SET_SRC (cand->expr),0);
>>> +
>>> + if (abi_extension_candidate_p (cand->insn)
>>> + && (!get_defs (cand->insn, orig_src, NULL)))
>
> Excess braces.
> Hopefully check_gnu_style would have complained.
>
>>> + return abi_handle_regs (cand->insn);
>>> outcome = make_defs_and_copies_lists (cand->insn, set_pat, state);
>>> @@ -1036,6 +1160,15 @@ combine_reaching_defs (ext_cand *cand, const_rtx set_pat, ext_state *state)
>>> }
>>> }
>>> + rtx insn_set = single_set (cand->insn);
>>> +
>>> + machine_mode mode = (GET_MODE (XEXP (SET_SRC (insn_set), 0)));
>
> Excess braces.
> Also in a lot of other spots in your patch.
> Please read the coding conventions and the patch, once again, before submission?
> thanks
next prev parent reply other threads:[~2023-10-23 6:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 6:50 Ajit Agarwal
2023-10-20 23:56 ` Vineet Gupta
2023-10-21 10:14 ` Ajit Agarwal
2023-10-21 19:26 ` rep.dot.nop
2023-10-23 6:46 ` Ajit Agarwal [this message]
2023-10-23 14:10 ` Bernhard Reutner-Fischer
2023-10-24 7:36 ` Ajit Agarwal
2023-10-24 20:36 ` rep.dot.nop
2023-10-24 20:49 ` Vineet Gupta
2023-10-25 11:11 ` Ajit Agarwal
2023-10-27 17:16 ` Bernhard Reutner-Fischer
2023-10-27 22:39 ` Vineet Gupta
2023-10-28 10:26 ` Ajit Agarwal
2023-10-29 10:49 ` Ajit Agarwal
2023-10-28 10:25 ` Ajit Agarwal
2023-10-29 10:48 ` Ajit Agarwal
2023-10-25 11:08 ` Ajit Agarwal
2023-10-23 18:32 ` Vineet Gupta
2023-10-24 7:40 ` Ajit Agarwal
2023-10-24 9: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=fdf4e055-d811-4eae-b83a-100f27dfdb61@linux.ibm.com \
--to=aagarwa1@linux.ibm.com \
--cc=bergner@linux.ibm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gnu-toolchain@rivosinc.com \
--cc=jeffreyalaw@gmail.com \
--cc=rep.dot.nop@gmail.com \
--cc=richard.guenther@gmail.com \
--cc=segher@kernel.crashing.org \
--cc=vineetg@rivosinc.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).