On Tue, Feb 2, 2021 at 4:03 PM Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> 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.

We can certainly devise a more clever way to represent a paradoxical subreg,
but at least the actual operation (WIDEN_MINUS_LOW) would match what
the hardware can do.  OTOH we could simply accept half of a vector for
the _LOW (little-endial) or _HIGH (big-endian) op and have the expander
deal with subreg frobbing?  Not that I'd like that very much though, even
a VIEW_CONVERT <v8hi> (v4hi-reg) would be cleaner IMHO (not sure
how to go about endianess here ... the _LOW/_HIGH paints us into some
corner here)

A new IFN (direct optab?) means targets with existing support for _LO/HI
do not automatically benefit which is a shame.

> 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

Reply via email to