const_int vs. const_double on 64-bit vs. 32-bit build platform

[Georg-Johann Lay]

Hi, in avr.md there is

(define_insn "map_bitsqi"
  [(set (match_operand:QI 0 "register_operand"             "=d")
        (unspec:QI [(match_operand:SI 1 "const_int_operand" "n")
                    (match_operand:QI 2 "register_operand"  "r")]
                   UNSPEC_MAP_BITS))]
  ""
  {
    return avr_out_map_bits (insn, operands, NULL);
  })

(define_insn "map_bitshi"
  [(set (match_operand:HI 0 "register_operand"               "=&r")
        (unspec:HI [(match_operand:DI 1 "const_double_operand" "n")
                    (match_operand:HI 2 "register_operand"     "r")]
                   UNSPEC_MAP_BITS))]
  ""
  {
    return avr_out_map_bits (insn, operands, NULL);
  })


i.e. depending on operand size of operand1 it is a const_int operand or a
const_double operand.

Now it depends on the build platform if a specific value like
0x1234567812345678 is CONST_INT or CONST_DOUBLE: On a 32-bit build platform it
is CONST_DOUBLE because it does not for in 32 bits and on a 64-bit build
platform it is CONST_INT.

To add to the complication, the "n" constraint has to be decomposed into
several constraints. What rtx code should the constraint mention? const_int or
const_double? Or both?

Some constraint letters even require const_int and others require const_double
so that it is odd to factor out the build platform dependency.

Some targets set need_64bit_hwint which should fix the issue because then all
values in question were CONST_INT.

Is this a right use case for need_64bit_hwint?
Would it have other side effects like ABI changes, e.g. to the preprocessor?

Thanks for hints on this topic.

Johann