Hi, > -----Original Message----- > From: Gcc <gcc-bounces+kyrylo.tkachov=arm....@gcc.gnu.org> On Behalf > Of gengqi via Gcc > Sent: 03 September 2021 11:56 > To: gcc@gcc.gnu.org > Subject: How about providing an interface to fusing instructions via > scheduling > > When I was adding pipeline to my backend, some instructions needed to be > fused and I found that there was no suitable interface to implement my > requirements. > > > > My hope is that > > 1. Do instruction scheduling and combine any two instructions, and > sometimes > the two instructions can be treated as 1 when they are issued > > 2. The two instructions only work better when they are immediately adjacent > to each other > > 3. An instruction can only be fused once, i.e. if the current instruction > has been fused with the previous one, the next one cannot be fused with the > current one. > > > > I have referred to numerous interfaces in the “GCC INTERNALS” which > implement some of my requirements, but all of which just happen not to > cover > my needs completely.
Indeed, there are a few places in GCC that help, but not a clean catch-all solution. > > > > These interfaces are： > > - bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx insn *prev, rtx insn > *curr) > > The name of the interface looks a lot like what I need. But in reality I > found that this interface only fuses instructions that are already adjacent > to each other and does not do scheduling (not satisfy 1). And this interface > may fuse 3 or more instructions (not satisfy 3). Indeed, this interface ensures that instructions that are already adjacent are kept together, but doesn't bring them together from far away. > > > > - void TARGET_SCHED_FUSION_PRIORITY (rtx insn *insn, int max_pri, int > *fusion_pri, int *pri) > > This interface is very powerful, but with only one insn being processed at a > time, this interface does not seem to be suitable for context sensitive > situations. > This is likely more appropriate for your needs. You may want to look in the implementation of this (and related) hook in the aarch64 backend. We use it there to bring certain loads and stores together with the intent to form special load/store-pair instructions. The scheduler brings them insns together, but we rely on post-scheduling peepholes to actually combine the two together into a single instruction. Although there are a few cases where it misses opportunities, it works pretty well. Thanks, Kyrill > > > - Use (define_bypass number out_insn_names in_insn_names [guard]) > > The “bypass” does not guarantee that the instruction being dispatched is > immediately adjacent to (not satisfy 2). Moreover, bypass only handles > instructions with true dependence. > > > > - int TARGET_SCHED_REORDER (FILE *file, int verbose, rtx insn **ready, > int *n_readyp, int clock) and TARGET_SCHED_REORDER2() > > This interface allows free adjustment of ready instructions, but it is not > eay to get the last scheduled instruction. The last scheduled instruction > needs to be taken into account for fusion. > > > > - Use define_peephole2 > > Since the fused instructions are somehow identical to one instruction, it is > thought that a peephole might be a good choice. But “define_peephole2” > also does not schedule instructions. > > > > In summary, I have not found an interface that does both scheduling and > fusion. Maybe we should enhance one of the above interfaces, or maybe we > should provide a new one. I think it is necessary and beneficial to have an > interface that does both scheduling and fusion.
