https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91009
Bug ID: 91009
Summary: Bug with future PowerPC patches with lfiwax/lfiwzx
(related to PR 90822)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
In bug 90822, I opened the bug to clean up some old code.
This bug is separated from that bug, to track the original issue that got me
looking at the lfiwax/lfiwzx patterns. PR 90822 will remain to be the cleanup
items for the patterns.
In working on some patches for a future PowerPC processor, I discovered that
the lfiwax and lfiwzx patterns could cause an abort.
To understand this, the floatsi{sf,df}2_lfiwax pattern is generated by the
normal floatsi{sf,df}2 insn during expansion.
(define_insn_and_split "floatsi<mode>2_lfiwax"
[(set (match_operand:SFDF 0 "gpc_reg_operand" "=<Fv>")
(float:SFDF (match_operand:SI 1 "nonimmediate_operand" "r")))
(clobber (match_scratch:DI 2 "=wa"))]
"TARGET_HARD_FLOAT && TARGET_LFIWAX
&& <SI_CONVERT_FP> && can_create_pseudo_p ()"
"#"
""
[(pc)]
{
rtx dest = operands[0];
rtx src = operands[1];
rtx tmp;
if (!MEM_P (src) && TARGET_POWERPC64 && TARGET_DIRECT_MOVE)
tmp = convert_to_mode (DImode, src, false);
else
{
tmp = operands[2];
if (GET_CODE (tmp) == SCRATCH)
tmp = gen_reg_rtx (DImode);
if (MEM_P (src))
{
src = rs6000_force_indexed_or_indirect_mem (src);
emit_insn (gen_lfiwax (tmp, src));
}
else
{
rtx stack = rs6000_allocate_stack_temp (SImode, false, true);
emit_move_insn (stack, src);
emit_insn (gen_lfiwax (tmp, stack));
}
}
emit_insn (gen_floatdi<mode>2 (dest, tmp));
DONE;
}
[(set_attr "length" "12")
(set_attr "type" "fpload")])
In the future patches, there is a new "prefixed" attribute that determines if
an insn is prefixed or not. The GCC machinery calls extract_constrain_insn on
the insn before the first split in processing the "prefixed" attribute.
Unfortunately if you use the -mno-vsx option (which some of the tests in the
testsuite do), the only alternative ("wa") is not valid with the -mno-vsx
option.
As a quick fix, the solution is simple, add an alternative in the split
patterns that just uses "d" and not "wa", or eliminate the alternatives (since
the pattern is split before register allocation).
Ultimately the whole section should be cleaned up (i.e. PR 90822), but at the
very least, we will need the small change as the 'future' cpu changes are put
into the compiler.
