On Thu, Oct 15, 2020 at 04:14:39PM +0800, Hongtao Liu wrote:
> On Thu, Oct 15, 2020 at 1:37 AM Segher Boessenkool
> <seg...@kernel.crashing.org> wrote:
> > > + gcc_assert (can_div_trunc_p (SUBREG_BYTE (trueop0),
> > > + GET_MODE_SIZE (GET_MODE_INNER
> > > (mode)),
> > > + &subreg_offset));
> >
> > Why is this needed?
>
> I only found this interface for poly_uint64 division to get subreg_offset.
I mean, why do you have this assert at all?
> > > + if (!CONST_INT_P (j)
> > > + || known_ge (UINTVAL (j), l2 - subreg_offset))
> > > + {
> > > + success = false;
> > > + break;
> > > + }
> > > + }
> >
> > You don't have to test if the input RTL is valid. You can assume it is.
> >
>
> This test is for something like (vec_select:v2di (subreg:v4di
> (reg:v2di) 0)(parallel [ (const_int 2) (const_int 3)])).
> const_int 2 here is out of range. Are you meaning the upper rtx wouldn't
> exist?
Assuming this is LE: yes, this is just invalid. You can do whatever you
want with it (except ICE :-) )
> > subreg_offset will differ in meaning if big-endian; is this correct
> Yes.
> > there, do all the stars align so this code works out fine there as well?
>
> i found it's a bit tricky to adjust selection index for target
> BYTES_BIG_ENDIA != WORDS_BIG_ENDIAN.
> Especially for component mode smaller than word, Any interface to handle this?
For most things you want BYTES_BIG_ENDIAN, anything in a subreg here for
example. I don't know which of those vectors use; I cannot find it in
the documentation, either.
Segher
