Richard Biener <richard.guent...@gmail.com> writes: > 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)
Yeah. I don't really like this because it means that it'll be impossible to remove the redundant work in gimple. The extra elements are just a crutch to satisfy the type system. As far as Joel's patch goes, I was imagining that the new operation would be an internal function rather than a tree code. However, if we don't want that, maybe we should just emit separate conversions and a normal subtraction, like we would for (signed) x - (unsigned) y. Thanks, Richard
