https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #9 from Edwin Lu ---
After talking with Palmer a bit about this, it looks like there might be an
issue with regards to insn scheduler. With -fno-schedule-insns the vsetvl is
inserted after the branch instead of before https://godbolt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #8 from Vineet Gupta ---
(In reply to JuzheZhong from comment #7)
> I think Phase 3 early fusion should handle this scenario.
It is handling this, except that it fusing the 2nd into 1st which happens to be
before the BEQ, hence this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #7 from JuzheZhong ---
(In reply to Vineet Gupta from comment #4)
> (In reply to JuzheZhong from comment #2)
> > We need to split all insns since some of them are not the ultimate RVV
> > instruction pattern that depend on VL/VTYPE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #6 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #5)
> What's starting to rattle around in my brain is the for a loop, if the count
> is unknown, then we probably don't want to unroll as that's much more likely
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #4 from Vineet Gupta ---
(In reply to JuzheZhong from comment #2)
> We need to split all insns since some of them are not the ultimate RVV
> instruction pattern that depend on VL/VTYPE.
> And I don't think the vsetvli should be keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #3 from JuzheZhong ---
I can optimize it if I find the time. (Currently, I am busy with other
stuff).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #2 from JuzheZhong ---
We need to split all insns since some of them are not the ultimate RVV
instruction pattern that depend on VL/VTYPE.
And I don't think the vsetvli should be keep close VLE, instead, They are
redundant, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #1 from Vineet Gupta ---
So the way things seem to work here are in cprop_hardreg (just before vsetvl)
we have following:
(insn 44 18 47 4 (set (reg:DI 15 a5 [orig:139 _31 ] [139])
(unspec:DI [
(reg:DI 11 a1
