[RFC] extending usability of insv(,extv)

[Adrian Straetling]

Roger Sayle <roger@eyesopen.com> wrote on 20.12.2005 03:23:59:

>
> On Mon, 19 Dec 2005, Adrian Straetling wrote:
> > Having only one expander does not allow specifying a mode for both
> > versions. Leaving it empty defaults to DImode in store_bit_field and
> > results in the memory operand being loaded into a reg:DI first. :-/
> >
> > There seem to be two possible approaches:
> >
> > 1.  Insv actually has no mode.
> >
> >     If the mode of the third operand is left out (VOIDmode)
> >     than store_bit_field should not attempt to change the mode of the
> >     operand, but simply handing it over to the backend to deal with it.
> >     If the backend provides a mode store_bit_field should use it like
it
> >     does now.
> >
> > 2.  Insv may have any mode, handling different modes identical to all
> >     other insns: insvdi, insvqi etc.
> >
> >     This appears to be the cleaner solution.
> >
> > The same should apply to extv where I face similar problems.
> >
> > Any comments or hints are appreciated.
>
>
...
>
> I'd be interested in seeing how difficult it would be generalize insv
> and extv following option 2 above.  One nice feature, is that optab
> construction could be made backwards compatible with machine descriptions
> allows the old-style "insv" to be treated like the new-style "insvsi".
> I remember in the past thinking that these could even be convert_optabs
> taking a pair of modes, one for the source and the other for the
> destination, but the AVR problem that inspired that line of thinking
> I've long since forgotten.
I guess that insv taking two modes would probably be the best solution. The
modes are not connected to each other in theory and on S/390 exist
instructions to support several different mode combinations.

> The ugliness with your patch to overload the meaning of VOIDmode on
> the third operand insv/extv is that this may potentially interfere or
> conflict with the interpretation of const_int operands.  The current
> code for assuming VOIDmode implies word_mode, simply provides the width
> for integer constants.
I see. At first, I wanted to rewrite the 4 back ends which do not provide a
mode, but looking into it more closely these back ends rely on the implicit
word_mode conversion to emit special patterns fo each word_mode.
If we decided to stay with option 1, I would think sth. like

*************** store_bit_field (rtx str_rtx, unsigned H
*** 618,626 ****
        rtx xop0 = op0;
        rtx last = get_last_insn ();
        rtx pat;
!       enum machine_mode maxmode = mode_for_extraction (EP_insv, 3);
        int save_volatile_ok = volatile_ok;

        volatile_ok = 1;

        /* If this machine's insv can only insert into a register, copy OP0
--- 618,629 ----
        rtx xop0 = op0;
        rtx last = get_last_insn ();
        rtx pat;
!       enum machine_mode maxmode = insn_data[(int)
CODE_FOR_insv].operand[3].mode;
        int save_volatile_ok = volatile_ok;

+       if (maxmode == VOIDmode)
+         {
+           maxmode = GET_MODE(value);
+           if (GET_CODE (value) == CONST_INT)
+             value = gen_int_mode (INTVAL (value), word_mode);
+         }
        volatile_ok = 1;

        /* If this machine's insv can only insert into a register, copy OP0

should preserve the old behaviour concerning CONST_INTs. Given I did not
make an error in distinguishing the modes for operand0 and operand3 it
should also work for the concerned 4 back ends as operand0 still has
word_mode.

> Perhaps one of GCC's architects will express an opinion, but I'm curious
> enough about your option 2 to prefer that unless there are some
unforeseen
> complications.  Certainly worth a feasability study.

Thanks for your thoughts on this!
Unfortunately I will not have the time to investigate here further since
I'm facing other duties, but maybe my collegues want to.

Bye,
Adrian