https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
--- Comment #4 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Andrew Pinski from comment #1)
> This is backend issue:
> //(insn 27 31 28 (set (reg/v:VNx2DI 37 v5 [orig:98 v0 ] [98])
> // (unspec:VNx2DI [
> // (reg:VNx2BI 68 p0 [orig:105 pg ] [105])
> // (plus:VNx2DI (mult:VNx2DI (reg/v:VNx2DI 37 v5 [orig:98 v0
> ] [98])
> // (reg/v:VNx2DI 33 v1 [orig:96 v18 ] [96]))
> // (reg/v:VNx2DI 32 v0 [orig:97 v19 ] [97]))
> // (const_vector:VNx2DI repeat [
> // (const_int 0 [0])
> // ])
> // ] UNSPEC_SEL)) "/app/example.c":15:14 7415
> {*cond_fmavnx2di_any}
> // (nil))
> movprfx z5.d, p0/z, z5.d // 27 [c=4 l=8]
> *cond_fmavnx2di_any/2
> mad z5.d, p0/m, z1.d, z0.d
No. I am not saying the issue of "movprfx". I am saying the issue of the
redundant "mov" instructions.:
mov z5.d, z24.d
mov z4.d, z25.d
mov z3.d, z26.d
mov z2.d, z27.d
This is the issue that "subreg" didn't propagate across the basic block.
