Re: [PATCH] Fix PR84101, account for function ABI details in vectorization costs

[Jeff Law <law@redhat.com>]

[ Returning to an old patch... ]
On 02/14/2018 04:52 AM, Richard Biener wrote:
> On Tue, 13 Feb 2018, Jeff Law wrote:
> 
>> On 01/30/2018 02:59 AM, Richard Biener wrote:
>>>
>>> This patch tries to deal with the "easy" part of a function ABI,
>>> the return value location, in vectorization costing.  The testcase
>>> shows that if we vectorize the returned value but the function
>>> doesn't return in memory or in a vector register but as in this
>>> case in an integer register pair (reg:TI ax) (bah, ABI details
>>> exposed late?  why's this not a parallel?) we end up spilling
>>> badly.
>> PARALLEL is used when the ABI mandates a value be returned in multiple
>> places.  Typically that happens when the value is returned in different
>> types of registers (integer, floating point, vector).
>>
>> Presumably it's not a PARALLEL in this case because the value is only
>> returned in %eax.
> 
> It's returned in %eax and %rdx (TImode after all).  But maybe
> "standard register pairs" are not represented as PARALLEL ...
Register pairs and PARALLELs handle two different issues.

A register pair such as eax/edx is used to hold a value that is larger
than a single register.

A PARALLEL is used to hold a return value that has to appear in multiple
places.  So for example a0/d0 on m68k in some circumstances.

They can even be combined.  You might have eax/edx as the first entry in
a parallel with xmm0 as the second entry.  That would indicate a TImode
value that is in eax/edx as well as in xmm0.

From the standpoint of costing the spills for a return value we can
generate the return value into any object in the PARALLEL, but we will
have to copy it to all the other objects in the PARALLEL.

So if none of the objects in the PARALLEL are suitable for vector
operations, then obviously we're going to have to copy from the vector
register to all the elements in the PARALLEL.  This is the most
expensive case.

If one of the objects in the PARALLEL is suitable for vector ops, then
that's where we want the result to end up.  We still have to copy the
result to the other elements in the PARALLEL, but it's one less
copy/spill than the previous case.

Note that copying might have to go through memory on some targets if the
registers in the PARALLEL are in different register files.

CONCAT is (IIRC) not supposed to show up in the RTL chain at all.

Note that expr.c may do something stupid with vectors.  Just looking at
emit_group_load_1 makes me wonder if everything is going to go through
memory when we've got PARALLELs and vectors.  That may actually make
your changes to vect_mode_store_cost more correct.

Jeff