Andrew Stubbs <a...@codesourcery.com> writes:
> 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.
What I more meant was: where do the moves that introduce the new
pseudos get created?
Almost all targets' move patterns introduce new pseudos if
can_create_pseudo_p in certain circumstances, so GCN isn't doing
anything unusual in the outline above. I think it comes down to
the specifics of which kinds of operands require these temporaries
and where the moves are being introduced.
AIUI IRA normally calls expand_reg_info () at a suitable point
to cope with new pseudos. It sounds like we might be missing
a call somewhere.
Richard
