"H.J. Lu" <hjl.to...@gmail.com> writes:
> On Tue, Jun 25, 2019 at 12:58 AM Uros Bizjak <ubiz...@gmail.com> wrote:
>>
>> On 6/25/19, Hongtao Liu <crazy...@gmail.com> wrote:
>> > On Sat, Jun 22, 2019 at 3:38 PM Uros Bizjak <ubiz...@gmail.com> wrote:
>> >>
>> >> On Fri, Jun 21, 2019 at 8:38 PM H.J. Lu <hjl.to...@gmail.com> wrote:
>> >>
>> >> > > > > > > > > > >> > > +/* Register pair. */
>> >> > > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 2); /* P2QI
>> >> > > > > > > > > > >> > > */
>> >> > > > > > > > > > >> > > +VECTOR_MODES_WITH_PREFIX (P, INT, 4); /* P2HI
>> >> > > > > > > > > > >> > > P4QI */
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > > I think
>> >> > > > > > > > > > >> > >
>> >> > > > > > > > > > >> > > INT_MODE (P2QI, 16);
>> >> > > > > > > > > > >> > > INT_MODE (P2HI, 32);
>> >> > > > > Why P2QI need 16 bytes but not 2 bytes?
>> >> > > > > Same question with P2HI.
>> >> > > >
>> >> > > > Because we made a mistake. It should be 2 and 4, since these
>> >> > > > arguments
>> >> > > Then it will run into internal comiler error when building libgcc.
>> >> > > I'm still invertigating it.
>> >> > > > are bytes, not bits.
>> >> >
>> >> > I don't think we can have 2 integer modes with the same number of bytes
>> >> > since
>> >> > it breaks things like
>> >> >
>> >> > scalar_int_mode wider_mode = GET_MODE_WIDER_MODE (mode).require ();
>> >> >
>> >> > We can get
>> >> >
>> >> > (gdb) p mode
>> >> > $2 = {m_mode = E_SImode}
>> >> > (gdb) p wider_mode
>> >> > $3 = {m_mode = E_P2HImode}
>> >> > (gdb)
>> >> >
>> >> > Neither middle-end nor backend support it.
>> >>
>> >> Ouch... It looks we hit the limitation of the middle end (which should
>> >> at least warn/error out if two modes of the same width are declared).
>> >>
>> >> OTOH, we can't solve this problem by using two HI/QImode registers,
>> >> since a consecutive register pair has to be allocated It is also not
>> >> possible to overload existing SI/HImode mode with different
>> >> requirements w.r.t register pair allocation (e.g. sometimes the whole
>> >> register is allocated, and sometimes a register pair is allocated).
>> >>
>> >> I think we have to invent something like SPECIAL_INT_MODE, which would
>> >> avoid mode promotion functionality (basically, it should not be listed
>> >> in mode_wider and similar arrays). This would prevent mode promotion
>> >> issues, while it would still allow to have mode, having the same width
>> >> as existing mode, but with special properties.
>> >>
>> >> I'm adding Jeff and Jakub to the discussion about SPECIAL_INT_MODE.
>> >>
>> >> Uros.
>> >
>> > Patch from H.J using PARTIAL_INT_MODE fixed this issue.
>> >
>> > +/* Register pair. */
>> > +PARTIAL_INT_MODE (HI, 16, P2QI);
>> > +PARTIAL_INT_MODE (SI, 32, P2HI);
>> > +
>>
>> I don't think this approach is correct (the mode is not partial), and
>> it could work by chance. The documentation is very brief with the
>> details of different mode types, so let's ask middle-end and RTL
>> experts.
Agree your SPECIAL_INT_MODE sounds cleaner FWIW. Having PARTIAL_INT_MODEs
that aren't actually partial seems pretty grim, but...
> It is used by powerpc backend for similar purpose:
>
> :/* Replacement for TImode that only is allowed in GPRs. We also use PTImode
> for quad memory atomic operations to force getting an even/odd register
> combination. */
> PARTIAL_INT_MODE (TI, 128, PTI);
...I guess this means that it's correct through usage.
Richard
