This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

machine description wish


The recent talk of define_address reminded me of a wish I had: the ability
to define multiple instances of a named insns in a machine description file.

The reason I want this is: it's very awkward to write insns which depend 
on the target processor, like this:

(define_expand "mulsi3"
  [(set (reg:SI 21)
        (mult:SI  (match_operand:SI 1 "arith_reg_operand" "")
                  (match_operand:SI 2 "arith_reg_operand" "")))
   (set (match_operand:SI 0 "arith_reg_operand" "")
        (reg:SI 21))]
  ""
  "
{
  rtx first, last;

  if (!TARGET_SH2)
    {
      ...
    }
  else
    {
      ...
    }
  DONE;
}")

This limitation seems to require unnecessarily exposing GCC compiler 
internals in the machine description which complicates writing
the machine description and also increases the support burden.

It seems the problem stems from having a single string for "type of 
insn" and "name of gen_function". If these were separated,
then the code generator could emit a parent function which checked
the constraints of functions until one matched.

So the previous example could be rewritten as two insns:

(define_insn "mulsi3" "mulsi3_sh1"
  [(set (match_operand:SI 0 "register_operand "=z")
...
  "!TARGET_SH2"
  "jsr @%1%#"
  [(set_attr "type" "sfunc")
   (set_attr "needs_delay_slot" "yes")])

(define_expand "mulsi3" "mulsi3_sh2_and_above"
  [(set (match_operand:SI 0 "register_operand" "=z")
...
  "TARGET_SH2"
  "mul.l %1,%0"
  [(set_attr "type" "dmpy")])

and then genemit could automatically generate the following code
to call the two mulsi3 functions:

rtx
gen_mulsi3(operand0, operand1, operand2)
     rtx operand0;
     rtx operand1;
     rtx operand2;
{
  if (!TARGET_SH2)
    return gen_mulsi3_sh1(operand0, operand1, operand2)
  else if (TARGET_SH2)
    return gen_mulsi3_sh2_and_above(operand0, operand1, operand2);
  return NULL_RTX;
}

Am I missing any details which would hinder implementation of this feature?

Toshi



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]