On 7/27/25 3:35 AM, Artemiy Volkov wrote:
From: Artemiy Volkov <arte...@synopsys.com>
Some of the instruction pairs recognized as fusible by a preceding
invocation of the dep_fusion pass require that both components of a pair
have the same hard register output for the fusion to work in hardware.
(An example of this would be a multiply-add operation, or a zero-extract
operation composed of two shifts.)
For all such pairs, the following conditions will hold:
(a) Both insns are single_sets
(b) Both insns have a register destination
(c) The pair has been marked as fusible by setting the second insn's
SCHED_GROUP flag
(d) Additionally, post-RA, both instructions' destination regnos are
equal
(All of these conditions are encapsulated in the newly created
single_output_fused_pair_p () predicate.)
During IRA, if conditions (a)-(c) above hold, we need to tie the two
instructions' destination allocnos together so that they are allocated
to the same hard register. We do this in add_insn_allocno_copies () by
adding a constraint conflict to the output operands of the two
instructions.
gcc/ChangeLog:
* ira-conflicts.cc (add_insn_allocno_copies): Handle fused insn pairs.
* rtl.h (single_output_fused_pair_p): Declare new function.
* rtlanal.cc (single_output_fused_pair_p): Define it.
Conceptually OK. I slightly worry about the use of PREV_INSN as we
could conceptually end up with notes, line markers, etc between the two
fusible insns.
Right now the scheduler is the only pass that ever examines
SCHED_GROUP_P and, IIRC, we remove all the notes from the IL, schedule,
then put all the notes back in. Point being within the scheduler
PREV_INSN is always going to get us the previous real insn. Outside the
scheduler context PREV_INSN might not do exactly what we want and may
even introduce compare-debug failures.
ISTM it's probably safer to use prev_nonnote_nondebug_insn. The biggest
worry with using that API is walking past a BB marker. But in the
fusion case, I think we're going to be safe from those problems.
Given the simplicity of this patch, I'd be inclined to ACK it
independent of the main body of work, so if you could bootstrap and
regression test it in isolation after adjusting the PREV_INSN uses it'd
be appreciated.
Jeff
