Richard Biener <richard.guent...@gmail.com> writes:
> On Mon, Sep 17, 2018 at 2:40 PM Andrew Stubbs <a...@codesourcery.com> wrote:
>> On 17/09/18 12:43, Richard Sandiford wrote:
>> > OK, sounds like the cost of vec_construct is too low then. But looking
>> > at the port, I see you have:
>> >
>> > /* Implement TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST. */
>> >
>> > int
>> > gcn_vectorization_cost (enum vect_cost_for_stmt ARG_UNUSED (type_of_cost),
>> > tree ARG_UNUSED (vectype), int ARG_UNUSED (misalign))
>> > {
>> > /* Always vectorize. */
>> > return 1;
>> > }
>> >
>> > which short-circuits the cost-model altogether. Isn't that part
>> > of the problem?
>>
>> Well, it's possible that that's a little simplistic. ;-)
>>
>> Although, actually the elementwise issue predates the existence of
>> gcn_vectorization_cost, and the default does appear to penalize
>> vec_construct somewhat.
>>
>> Actually, the default definition doesn't seem to do much besides
>> increase vec_construct, so I'm not sure now why I needed to change it?
>> Hmm, more experiments to do.
>>
>> Thanks for the pointer.
>
> Btw, we do not consider to use gather/scatter for VMAT_ELEMENTWISE,
> that's a missed "optimization" quite possibly because gather/scatter is so
> expensive on x86. Thus the vectorizer should consider this and use the
> cheaper alternative according to the cost model (which you of course should
> fill with sensible values...).
Do you mean it this way round, or that it doesn't consider using
VMAT_ELEMENTWISE for natural gather/scatter accesses? We do use
VMAT_GATHER_SCATTER instead of VMAT_ELEMENTWISE where possible for SVE,
but that relies on implementing the new optabs instead of using the old
built-in-based interface, so it doesn't work for x86 yet.
I guess we might need some way of selecting between the two if
the costs of gather and scatter are context-dependent in some way.
But if gather/scatter is always more expensive than VMAT_ELEMENTWISE
for certain modes then it's probably better not to define the optabs
for those modes.
Thanks,
Richard
