https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81434
Wilco <wilco at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-07-20
Ever confirmed|0 |1
--- Comment #6 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to jim.wilson from comment #5)
> On Wed, Jul 19, 2017 at 4:25 AM, wilco at gcc dot gnu.org
> <gcc-bugzi...@gcc.gnu.org> wrote:
> > To more accurately schedule fusion pairs wouldn't we need to specify the
> > scheduling behaviour of the group as well? From the dumps below it schedules
> > the adrp/add in the same cycle if we're lucky, but it is modelled as using 2
> > ALUs rather than a new single fused instruction.
>
> The fusion pair takes two issue slots and uses one alu, but is modeled
> as taking two issues slots and using two alus. I haven't tried to
> address this problem. I'm just trying to get the issue slot handling
> correct for now, so that they can issue in the same cycle.
Do you think it might be feasible to update resource usage of a schedule group?
Or would it be easier to replace a fused pair with a single instruction with
correct resource usage, and expand after scheduling in say split5?
For some cases (single destination reg like ADRP/ADD, AES, MOV/MOVK) it would
be simpler to treat them as a single instruction from early on.
> > Also is your change fixing the issue that the scheduler cannot schedule 2
> > instructions with a zero latency dependency between them in the same cycle?
> > That's a very similar bug.
>
> The scheduler can schedule 2 insns w/ zero latency dependency in the
> same cycle. However, it does not do so when a SCHED_GROUP is
> involved. This is the bug that my patch fixes.
You're right, now I try a few cases, it works fine on non-fused instructions -
I can't find my original example but it's possible it was caused by fused
instructions messing up the schedule.
