On Tue, 2025-01-21 at 21:23 +0800, Xi Ruoyao wrote:
/* snip */
> > It seems to be more formal through TARGET_SCHED_MACRO_FUSION_P and
> >
> > TARGET_SCHED_MACRO_FUSION_PAIR_P. I found the spec test item that
> > generated
> >
> > this instruction pair. I implemented these two hooks to see if it
> > works.
>
> And another problem is w/o bstrpick_alsl_paired some test cases are
> regressed, like:
>
> struct Pair { unsigned long a, b; };
>
> struct Pair
> test (struct Pair p, long x, long y)
> {
> p.a &= 0xffffffff;
> p.a <<= 2;
> p.a += x;
> p.b &= 0xffffffff;
> p.b <<= 2;
> p.b += x;
> return p;
> }
>
> in GCC 13 the result is:
>
> or $r12,$r4,$r0
Hmm, this strange move is caused by "&" in bstrpick_alsl_paired. Is it
really needed for the fusion?
> bstrpick.d $r4,$r12,31,0
> alsl.d $r4,$r4,$r6,2
> or $r12,$r5,$r0
> bstrpick.d $r5,$r12,31,0
> alsl.d $r5,$r5,$r6,2
> jr $r1
>
> But now:
>
> addi.w $r12,$r0,-4 # 0xfffffffffffffffc
> lu32i.d $r12,0x3
> slli.d $r5,$r5,2
> slli.d $r4,$r4,2
> and $r5,$r5,$r12
> and $r4,$r4,$r12
> add.d $r4,$r4,$r6
> add.d $r5,$r5,$r6
> jr $r1
>
> While both are suboptimial, the new code generation is more stupid. I'm
> still unsure how to fix it, so maybe for now we'd just restore
> bstrpick_alsl_paired to fix the regression.
>
> And I guess we'd need zero_extend_ashift anyway because we need to use
> alsl.d instead of slli.d for the fusion.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
