On 17/09/18 10:22, Richard Sandiford wrote:
<a...@codesourcery.com> writes:
The IRA pass makes an assumption that any pseudos created after the pass begins
were created explicitly by the pass itself and therefore will have
corresponding entries in its other tables.
The GCN back-end, however, often creates additional pseudos, in expand
patterns, to represent the necessary EXEC value, and these break IRA's
assumption and cause ICEs.
This patch simply has IRA skip unknown pseudos, and the problem goes away.
Presumably, it's not ideal that these registers have not been processed by IRA,
but it does not appear to do any real harm.
Could you go into more detail about how this happens? Other targets
also create pseudos in their move patterns.
Here's a simplified snippet from the machine description:
(define_expand "mov<mode>"
[(set (match_operand:VEC_REG_MODE 0 "nonimmediate_operand")
(match_operand:VEC_REG_MODE 1 "general_operand"))]
""
{
[...]
if (can_create_pseudo_p ())
{
rtx exec = gcn_full_exec_reg ();
rtx undef = gcn_gen_undef (<MODE>mode);
[...]
emit_insn (gen_mov<mode>_vector (operands[0], operands[1], exec
undef));
[...]
DONE;
}
})
gcn_full_exec_reg creates a new pseudo. It gets used as the mask
parameter of a vec_merge.
These registers then trip the asserts in ira.c.
In the case of setup_preferred_alternate_classes_for_new_pseudos it's
because they have numbers greater than "start" but have not been
initialized with different ORIGINAL_REGNO (why would they have been?)
In the case of move_unallocated_pseudos it's because the table
pseudo_replaced_reg only has entries for the new pseudos directly
created by find_moveable_pseudos, not the ones created indirectly.
Andrew
