Re: [PATCH 16/25] Fix IRA ICE.

[Richard Sandiford <richard dot sandiford at arm dot com>]

Andrew Stubbs <ams@codesourcery.com> writes:
> On 17/09/18 10:22, Richard Sandiford wrote:
>> <ams@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