> The explicit conversions I see are because we need the output of the > conversion in multiple vfmul instructions. That won't be helped by > the patch you've proposed.
FWIW on my local branch and the patch applied I see that the vfwmuls are being generated (all of the vfmuls are replaced). > It'll need to be a define_insn_and_split as its a 3->3 splitter. The > split will emit the two extensions and the widening multiply as 3 > distinct insns. I tried this and while it worked for the first vfwmul the subsequent ones are not being combined/optimized. Now I'm not a combine expert at all but it looks as if the source float_extends are being deleted deferring deletion of insn with uid = 39. deferring deletion of insn with uid = 37. with that pattern successfully matched, while they are only "rescanned" with the synthetic "single widen" one. Them being deleted (or rather absorbed by the vfwmul) no further combination is possible (until after split?) This seems to be a fundamental difference between the two approaches. Maybe the "double widen" pattern can be adjusted to also handle this or I did something wrong when writing the splitter? With the "single widen" pattern, however, it works more or less naturally therefore I'd still suggest going for it. Regards Robin
