[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

andrea.corallo at arm dot com gcc-bugzilla@gcc.gnu.org
Wed Dec 9 16:39:04 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092

--- Comment #5 from Andrea Corallo <andrea.corallo at arm dot com> ---
"rsandifo at gcc dot gnu.org via Gcc-bugs" <gcc-bugs@gcc.gnu.org>
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> (In reply to Andrea Corallo from comment #3)
>> Created attachment 49710 [details]
>> PR97092.patch
>> 
>> What is going on is that in 'update_costs_from_allocno' we try to
>> identify the smallest mode using narrower_subreg_mode to then update the
>> costs.
>> 
>> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> are not ordered we ICE in 'paradoxical_subreg_p'.
>> 
>> Now I don't know if the strategy we want is:
>> 
>> - In 'update_costs_from_allocno' when modes are not ordered instead of
>>   calling 'narrower_subreg_mode' just keep the current one.
>> 
>> - Always select the cheapest mode in terms of cost.
>> 
>> The attached I'm testing implements the second.

Hi Richard,

thanks for commenting.

> I think instead we should consider recomputing “mode” in each
> iteration of the loop, rather than carry over the result of
> previous iterations.  I.e. use:
>
>     mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>                                  ALLOCNO_MODE (cp->second));

Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
(cp->second) always satisfying 'ordered_p'?  In case not I think we
can't use 'narrower_subreg_mode'.

I thought we select the smallest because is the cheapest, so not to use
'narrower_subreg_mode' I compared directly the costs.

> instead of:
>
>     mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
>
> Before g:e2323a2b77c91d1ba8194b01e6deaa2e00f15990 “mode”
> was a loop invariant, so it made sense to set it outside
> the loop.  I think the intention of that patch was to use
> the smaller of the two modes involved in the copy, and carrying
> the result over to future copies might have been unintentional.
>
> The difficulty with carrying the mode over to later copies
> is that the costs then become dependent on the order of
> the copies, whereas I'm not sure the order of the copies
> is significant.

I see

Thanks!

  Andrea


More information about the Gcc-bugs mailing list