On Mon, Feb 1, 2021 at 6:54 PM Joel Hutton <joel.hut...@arm.com> wrote: > > Hi Richard(s), > > I'm just looking to see if I'm going about this the right way, based on the > discussion we had on IRC. I've managed to hack something together, I've > attached a (very) WIP patch which gives the correct codegen for the testcase > in question (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772). It would > obviously need to support other widening patterns and differentiate between > big/little endian among other things. > > I added a backend pattern because I wasn't quite clear which changes to make > in order to allow the existing backend patterns to be used with a V8QI, or > how to represent V16QI where we don't care about the top/bottom 8. I made > some attempt in optabs.c, which is in the patch commented out, but I'm not > sure if I'm going about this the right way.
Hmm, as said, I'd try to arrange like illustrated in the attachment, confined to vectorizable_conversion. The only complication might be sub-optimal code-gen for the vector-vector CTOR compensating for the input vector (on RTL that would be a paradoxical subreg from say V4HI to V8HI) Richard. > Joel
p
Description: Binary data
