This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RTL alternative selection question
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Andrew Stubbs <andrew_stubbs at mentor dot com>
- Cc: Richard Sandiford <richard dot sandiford at arm dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 1 Oct 2019 19:07:32 -0500
- Subject: Re: RTL alternative selection question
- References: <1a7febb4-197e-eca7-4fcf-99bf5cb8bdf6@mentor.com> <20190923141517.GH9749@gate.crashing.org> <57be9ba9-94b3-3aea-37ce-ca2cd55bd34c@mentor.com> <4e2f4125-a19d-aef2-77f7-ba65d7f2b528@mentor.com>
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