Re: Revision 166517 caused PR 46414

["H.J. Lu" <hjl dot tools at gmail dot com>]

2010/11/10 Jan Hubicka <hubicka@ucw.cz>:
>> 2010/11/10 Jan Hubicka <hubicka@ucw.cz>:
>> >> On Wed, Nov 10, 2010 at 7:18 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> >> >> The complette unrilling seems sane here.
>> >> >> This seems like good idea to me and i am not quite sure why 32bit compilation does not do the
>> >> >> transofrm. I will check now.
>> >> >
>> >> > The reason is word size. ?We compute move costs based on this, so vectorized moves are more expensive
>> >> > in 32bit cost model than 64bit.
>> >> > Perhaps there is way to hook vectorizer cost model in here?
>> >> >
>> >>
>> >> Shouldn't we use vector size to compute move cost for vector move?
>> >
>> > That would work for me. ?I am not terribly familiar with vector costs here, could you try to patch
>> > estimate_move_cost in tree-inline.c?
>> > We are very simplistic here assuming that pretty much all operations have cost of 1, so I guess
>> > making all vector moves to have cost 1 is fine. The main reason for that function is to catch large
>> > structure copies.
>> >
>>
>> How about this patch?
>> + ?if (TREE_CODE (type) == VECTOR_TYPE)
>> + ? ?{
>> + ? ? ?enum machine_mode inner = TYPE_MODE (TREE_TYPE (type));
>> + ? ? ?enum machine_mode simd
>> + ? ? = targetm.vectorize.preferred_simd_mode (inner);
>> + ? ? ?return GET_MODE_SIZE (TYPE_MODE (type)) / GET_MODE_SIZE (simd);
>> + ? ?}
>
> You need to round up, so we don't end up with cost of 0 for small blocks. Other than that it seems fine to me.
> We will probably eventually need to also update the expander to use vector instructions when possible to match
> the costs, but I guess most of vectors we see in the code are already of proper size.
>

Like this?  OK for trunk?

Thanks.

-- 
H.J.

Attachment: gcc-pr46414-2.patch
Description: Text document