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
