This is the mail archive of the
mailing list for the GCC project.
Re: Instruction scheduling for the R5900's 2 integer pipelines
- From: Woon yung Liu <ysai187 at yahoo dot com>
- To: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 20 Jan 2016 10:12:39 +0000 (UTC)
- Subject: Re: Instruction scheduling for the R5900's 2 integer pipelines
- Authentication-results: sourceware.org; auth=none
- References: <569E6367 dot 4020205 at redhat dot com>
- Reply-to: Woon yung Liu <ysai187 at yahoo dot com>
A few days ago, I think that I got the 2nd pipeline to get scheduled during testing. But I never understood why it worked.
It happened when I modified the existing patterns like this, as how I saw the new constraints that were added into the old GCC v3.2.2 port:
[(set (match_operand:GPR 0 "register_operand" "=d,lwl")
But because I didn't see the GCC internals documentation mention that it's the correct way to be listing alternative constrains, I changed them to all be like this and then scheduling stopped working in the desired way:
[(set (match_operand:GPR 0 "register_operand" "=d,l,wl")
l is the original lo register constraint, while wl is the new lo1 register constraint.
Did I originally add in the new register constraints correctly, meaning that this is either an undocumented feature or I totally missed reading a part of the documentation?
Or am I actually exploiting a glitch?
I still don't have a copy of the Cygnus GCC release that had support for the R5900.
It's n another HDD unit that isn't going to be with me until at least this weekend.
The GCC v3.2.2 port that I have, shows some scheduling code that might have been from the old Cygnus release. It tries to consolidate r5900imuldiv instructions for the register allocator to work out, but is disabled (returns immediately) and is incomplete (no instructions were tagged r5900imuldiv).