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 <guoji...@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
> +
>
>
> /* 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;
> +}
