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

["jim.wilson at linaro dot org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81434

--- Comment #7 from jim.wilson at linaro dot org ---
On Thu, Jul 20, 2017 at 4:20 AM, wilco at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> 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.

I haven't looked at this issue yet.  This problem wastes one issue
slot per cycle, where as the SCHED_GROUP problem wastes up to N-1
issue slots per cycle, where N is the issue rate.  For falkor, this is
up to 3 issue slots per cycle.  Since the SCHED_GROUP problem is more
serious, I looked at that one first.

Thinking about this a bit, I don't know if there is an easy way to
correct resource usage for a fused pair if represented as two insns.
If we represent a fused pair as a single instruction, then we are
getting the issue count wrong, as they take two issue slots, but one
function unit slot.  However, there is a way to deal with the issue
count.  We could use TARGET_SCHED_VARIABLE_ISSUE to make the single
fused insn take two issue slots.  I already wrote a patch like that
for a different reason as an experiment so I know this can work.  We
may also have to worry about instruction lengths, depending on when
exactly we split the fused insn into two insns.  There could be some
other details that turn up when we try to implement this.  What do we
do if a fused insn takes the last issue slot for instance?  Maybe we
try to prevent that, or maybe we reduce the issue rate by one for the
next cycle.  This may depend on how the hardware implements insn
fusing.