>>> In practice this will only affect targets that choose to use mixed >>> vector sizes, and I think it's reasonable to optimise only for the >>> case in which such targets support widening conversions. So what >>> do you think about the idea of emitting separate conversions and >>> a normal subtract? We'd be relying on RTL to fuse them together, >>> but at least there would be no redundancy to eliminate. >> >> So in vectorizable_conversion for the widen-minus you'd check >> whether you can do a v4qi -> v4hi and then emit a conversion >> and a wide minus? > >Yeah.
This seems reasonable, as I recall we decided against adding internal functions for the time being as all the existing vec patterns code would have to be refactored. So emit a v4qi->v8qi gimple conversion then a regular widen_lo/hi using the existing backend patterns/optabs?