Andrew Stubbs <andrew_stu...@mentor.com> writes:
> On 23/09/2019 15:15, Segher Boessenkool wrote:
>> On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
>>> [(set (match_operand:DI 0 "register_operand" "=Sg,v")
>>> (ashift:DI
>>> (match_operand:DI 1 "gcn_alu_operand" " Sg,v")
>>> (match_operand:SI 2 "gcn_alu_operand" " Sg,v")))
>>> (clobber (match_scratch:BI 3 "=cs,X"))]
>>
>>> Unfortunately, the compiler (almost?) exclusively selects the second
>>> alternative, even when this means moving the values from one register
>>> file to the other, and then back again.
>>>
>>> The problem is that the scalar instruction clobbers the CC register,
>>> which results in a "reject++" for that alternative in the LRA dump.
>>
>> What kind of reject? It prints a reason, too.
>
> 0 Non input pseudo reload: reject++
It looks like that comes from:
/* Input reloads can be inherited more often than
output reloads can be removed, so penalize output
reloads. */
if (!REG_P (op) || curr_static_id->operand[nop].type != OP_IN)
{
if (lra_dump_file != NULL)
fprintf
(lra_dump_file,
" %d Non input pseudo reload: reject++\n",
nop);
reject++;
}
That's a good reason for increasing the cost of output reloads of values
vs. input reloads of values, but I don't think it covers your case of
reloading a SCRATCH, which can never be inherited anyway. So if the
reason in the comment is the real reason (definitely sounds plausible)
then perhaps we should just exclude SCRATCHes?
I don't think this is really target-specific. MIPS has a very similar
situation with multiplication, and again the SCRATCH reloads shouldn't
count. Same for some SVE patterns.
Richard
