https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116590
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kito at gcc dot gnu.org
--- Comment #5 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So the trick here is to understand where the problematic instruction comes
from. If you add "-dap" to the command line and look at the assembly you'll
see stuff like this:
th.vmv8r.v v8,v16 # 90 [c=4 l=4] *pred_maccrvvm8sf_scalar/3
th.vfmacc.vf v8,fa5,v24
That tells you what insn is generating that code - pred_maccrvvm8sf_scalar.
And if you look at that insn in the riscv backend you'll see that under certain
circumstances it will generate the vmv8r which apparently causes headaches.
As it turns out I was fixing a related problem last week. Specifically we have
insns that are generating multiple instructions and that's something we should
generally avoid. I fixed the integer versions of these patterns, but not the
floating point versions.
I'll take care of the problematical tm.vmv8r.v instructions.
I'm not sure how best to handle the recip estimator. I think the first
question is whether or not that should have been dealt with at the intrinsic
level or not. ie, should we have a recip estimator intrinsic available for
thead vector or not. Kito might have some opinions on that.
