Hi Michael,
As I was looking into extending support for __vector_pair to P9, I just
had a few concerns regarding the new type __dmf or the TDOmode. I have
listed them below.
On Fri, 2025-11-14 at 02:57 -0500, Michael Meissner wrote:
>
> +
> +;; TDOmode (__dmf keyword for 1,024 bit registers).
> +(define_expand "movtdo"
> + [(set (match_operand:TDO 0 "nonimmediate_operand")
> + (match_operand:TDO 1 "input_operand"))]
> + "TARGET_DENSE_MATH"
OO mode expand had a few problems due to which this predicate
"TARGET_DENSE_MATH" was moved inside the block and an error message was
printed when using "__vector_pair/__vector_quad" when -mno-mma.
I wonder if we should do the same thing here, otherwise some ICE
problems could potentially happen as seen in PR103353.
Simplest test case would be to use a builtin that requires __dmf and
compile using -mno-dense-math like this.
void
test4 (char *ptr)
{
__builtin_<some dense math builtin> ((__dmf *) ptr,...);
}
> +{
> + rs6000_emit_move (operands[0], operands[1], TDOmode);
> + DONE;
> +})
> +
> +(define_insn_and_split "*movtdo"
> + [(set (match_operand:TDO 0 "nonimmediate_operand"
> "=wa,m,wa,wD,wD,wa")
> + (match_operand:TDO 1 "input_operand" "m,wa,wa,wa,wD,wD"))]
Should we allow the "m" constrant? There was this PR110411 which
changed the constraint for OO/XO mode from altivec memory to vsx memory
operand "ZwO". But I guess the source of ICE was since memcpy was also
using the moves in OOmode, and since we wont do it in this case due to
lack of loads/stores to the dmrs themselves, the problem should not
happen here.
>
Thanks and regards,
Avinash Jayakar
