RTL alternative selection question

[Segher Boessenkool]

On Tue, Oct 01, 2019 at 01:12:06PM +0100, Andrew Stubbs wrote:
> On 23/09/2019 15:39, Andrew Stubbs wrote:
> >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++
> 
> Apparently I was confused by operand "0" versus alternative "0". That 
> message did occur, but it wasn't the only one. Here's all of it:
> 
>              0 Non input pseudo reload: reject++
>              3 Scratch win: reject+=2
>            alt=0,overall=9,losers=1,rld_nregs=2
>            alt=1,overall=6,losers=1,rld_nregs=2
> 
> I don't understand why the "reject++" occurs, but presumably has to do 
> with the "Sg" register availability somehow?

operands[0] (the output) needed a reload, apparently.

[ snip ]

> Unfortunately, removing the "Scratch win" penalty alone is not enough 
> for LRA to select the first alternative -- at least, no in my testcase 
> -- so I need to understand the "non input pseudo reload" issue as well. 
> I can see why it fires for alt0, but not why it does not fire for alt1.

The reload it decided to do there was for operands[1] or operands[2]?


Segher