This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
const_int vs. const_double on 64-bit vs. 32-bit build platform
- From: Georg-Johann Lay <avr at gjlay dot de>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 20 Jan 2012 15:09:02 +0100
- Subject: const_int vs. const_double on 64-bit vs. 32-bit build platform
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