Re: RTL alternative selection question

[Richard Sandiford <richard dot sandiford at arm dot com>]

Andrew Stubbs <andrew_stubbs@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