[Bug rtl-optimization/81434] AArch64 instruction fusing and pipeline scheduling problem

[wilco at gcc dot gnu.org]

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-bugzilla@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.