From: Jiufu Guo <guojiufu@linux.ibm.com>
To: Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org
Subject: ping^^: [PATCH] rs6000: Enable const_anchor for 'addi'
Date: Wed, 31 May 2023 11:00:09 +0800 [thread overview]
Message-ID: <7npm6hxl1i.fsf_-_@ltcden2-lp1.aus.stglabs.ibm.com> (raw)
In-Reply-To: <7ncz2zpi81.fsf@ltcden2-lp1.aus.stglabs.ibm.com> (Jiufu Guo via Gcc-patches's message of "Wed, 17 May 2023 14:47:26 +0800")
Gentle ping...
Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> Gentle ping...
>
> Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>
>> Hi,
>>
>> I'm thinking that we may enable this patch for stage1, so ping it.
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603530.html
>>
>> BR,
>> Jeff (Jiufu)
>>
>> Jiufu Guo <guojiufu@linux.ibm.com> writes:
>>
>>> Hi,
>>>
>>> There is a functionality as const_anchor in cse.cc. This const_anchor
>>> supports to generate new constants through adding small gap/offsets to
>>> existing constant. For example:
>>>
>>> void __attribute__ ((noinline)) foo (long long *a)
>>> {
>>> *a++ = 0x2351847027482577LL;
>>> *a++ = 0x2351847027482578LL;
>>> }
>>> The second constant (0x2351847027482578LL) can be compated by adding '1'
>>> to the first constant (0x2351847027482577LL).
>>> This is profitable if more than one instructions are need to build the
>>> second constant.
>>>
>>> * For rs6000, we can enable this functionality, as the instruction
>>> 'addi' is just for this when gap is smaller than 0x8000.
>>>
>>> * Besides enabling TARGET_CONST_ANCHOR on rs6000, this patch also fixed
>>> one issue. The issue is:
>>> "gcc_assert (SCALAR_INT_MODE_P (mode))" is an requirement for function
>>> "try_const_anchors".
>>>
>>> * One potential side effect of this patch:
>>> Comparing with
>>> "r101=0x2351847027482577LL
>>> ...
>>> r201=0x2351847027482578LL"
>>> The new r201 will be "r201=r101+1", and then r101 will live longer,
>>> and would increase pressure when allocating registers.
>>> But I feel, this would be acceptable for this const_anchor feature.
>>>
>>> * With this patch, I checked the performance change on SPEC2017, while,
>>> and the performance is not aggressive, since this functionality is not
>>> hit on any hot path. There are runtime wavings/noise(e.g. on
>>> povray_r/xalancbmk_r/xz_r), that are not caused by the patch.
>>>
>>> With this patch, I also checked the changes in object files (from
>>> GCC bootstrap and SPEC), the significant changes are the improvement
>>> that: "addi" vs. "2 or more insns: lis+or.."; it also exposes some
>>> other optimizations opportunities: like combine/jump2. While the
>>> code to store/load one more register is also occurring in few cases,
>>> but it does not impact overall performance.
>>>
>>> * To refine this patch, some history discussions are referenced:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
>>> https://gcc.gnu.org/pipermail/gcc-patches/2009-April/260421.html
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566744.html
>>>
>>>
>>> Bootstrap and regtest pass on ppc64 and ppc64le for this patch.
>>> Is this ok for trunk?
>>>
>>>
>>> BR,
>>> Jeff (Jiufu)
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/rs6000/rs6000.cc (TARGET_CONST_ANCHOR): New define.
>>> * cse.cc (cse_insn): Add guard condition.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc.target/powerpc/const_anchors.c: New test.
>>> * gcc.target/powerpc/try_const_anchors_ice.c: New test.
>>>
>>> ---
>>> gcc/config/rs6000/rs6000.cc | 4 ++++
>>> gcc/cse.cc | 3 ++-
>>> .../gcc.target/powerpc/const_anchors.c | 20 +++++++++++++++++++
>>> .../powerpc/try_const_anchors_ice.c | 16 +++++++++++++++
>>> 4 files changed, 42 insertions(+), 1 deletion(-)
>>> create mode 100644 gcc/testsuite/gcc.target/powerpc/const_anchors.c
>>> create mode 100644 gcc/testsuite/gcc.target/powerpc/try_const_anchors_ice.c
>>>
>>> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
>>> index d2743f7bce6..80cded6dec1 100644
>>> --- a/gcc/config/rs6000/rs6000.cc
>>> +++ b/gcc/config/rs6000/rs6000.cc
>>> @@ -1760,6 +1760,10 @@ static const struct attribute_spec rs6000_attribute_table[] =
>>>
>>> #undef TARGET_UPDATE_IPA_FN_TARGET_INFO
>>> #define TARGET_UPDATE_IPA_FN_TARGET_INFO rs6000_update_ipa_fn_target_info
>>> +
>>> +#undef TARGET_CONST_ANCHOR
>>> +#define TARGET_CONST_ANCHOR 0x8000
>>> +
>>> \f
>>>
>>> /* Processor table. */
>>> diff --git a/gcc/cse.cc b/gcc/cse.cc
>>> index b13afd4ba72..56542b91c1e 100644
>>> --- a/gcc/cse.cc
>>> +++ b/gcc/cse.cc
>>> @@ -5005,7 +5005,8 @@ cse_insn (rtx_insn *insn)
>>> if (targetm.const_anchor
>>> && !src_related
>>> && src_const
>>> - && GET_CODE (src_const) == CONST_INT)
>>> + && GET_CODE (src_const) == CONST_INT
>>> + && SCALAR_INT_MODE_P (mode))
>>> {
>>> src_related = try_const_anchors (src_const, mode);
>>> src_related_is_const_anchor = src_related != NULL_RTX;
>>> diff --git a/gcc/testsuite/gcc.target/powerpc/const_anchors.c b/gcc/testsuite/gcc.target/powerpc/const_anchors.c
>>> new file mode 100644
>>> index 00000000000..39958ff9765
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/powerpc/const_anchors.c
>>> @@ -0,0 +1,20 @@
>>> +/* { dg-do compile { target has_arch_ppc64 } } */
>>> +/* { dg-options "-O2" } */
>>> +
>>> +#define C1 0x2351847027482577ULL
>>> +#define C2 0x2351847027482578ULL
>>> +
>>> +void __attribute__ ((noinline)) foo (long long *a)
>>> +{
>>> + *a++ = C1;
>>> + *a++ = C2;
>>> +}
>>> +
>>> +void __attribute__ ((noinline)) foo1 (long long *a, long long b)
>>> +{
>>> + *a++ = C1;
>>> + if (b)
>>> + *a++ = C2;
>>> +}
>>> +
>>> +/* { dg-final { scan-assembler-times {\maddi\M} 2 } } */
>>> diff --git a/gcc/testsuite/gcc.target/powerpc/try_const_anchors_ice.c b/gcc/testsuite/gcc.target/powerpc/try_const_anchors_ice.c
>>> new file mode 100644
>>> index 00000000000..4c8a892e803
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/powerpc/try_const_anchors_ice.c
>>> @@ -0,0 +1,16 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O2" } */
>>> +
>>> +/* __builtin_stack_restore could generates {[%1:DI]=0;} in BLK mode,
>>> + it could case ICE in try_const_anchors which only supports SCALAR_INT. */
>>> +
>>> +long
>>> +foo (const int val)
>>> +{
>>> + if (val == (0))
>>> + return 0;
>>> + void *p = __builtin_stack_save ();
>>> + char c = val;
>>> + __builtin_stack_restore (p);
>>> + return c;
>>> +}
next prev parent reply other threads:[~2023-05-31 3:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 3:17 Jiufu Guo
2022-11-09 3:18 ` Ping: " Jiufu Guo
2023-04-26 5:39 ` ping: " Jiufu Guo
2023-05-17 6:47 ` Jiufu Guo
2023-05-31 3:00 ` Jiufu Guo [this message]
2023-05-31 13:40 ` ping^^: " David Edelsohn
2023-06-02 4:03 ` Jiufu Guo
2023-06-19 3:38 ` Jiufu Guo
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=7npm6hxl1i.fsf_-_@ltcden2-lp1.aus.stglabs.ibm.com \
--to=guojiufu@linux.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linkw@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).