On 8/15/26 3:37 AM, Jin Ma wrote:
I have found insn types useful, but I think they are better suited to
coarse instruction classification than to replacing exact RTL matching.
Understood. And that seems like a sensible approach.
First, the current machine description has insns that can easily be
misclassified from structural RTL alone. For example, a normal ADDI
can be:
addi a0,a0,1
(set (reg:DI 10 a0)
(plus:DI (reg:DI 10 a0)
(const_int 1)))
This is recognized by *adddi3 in riscv.md and has TYPE_ARITH. On the
other hand, consider this bit-manipulation insn:
binvi a0,a0,63
Its RTL is:
(set (reg:DI 10 a0)
(plus:DI (reg:DI 10 a0)
(const_int -9223372036854775808
[0x8000000000000000])))
No doubt. There's many examples scattered around where we have
potentially different ways to describe the operation in RTL. In fact,
that's kind of what I was worried about when using the types and when I
suggested perhaps we have some kind of fusion based attribute.
Splitting the fusion case off from the scheduler type means we can
change the fusion cases without impacting the scheduler at all. Of
course that does introduce additional work when we add new patterns.
But again, it was me thinking outloud about ways to simplify this in the
long term. IIRC attributes are used to drive things like CC0 tracking
in some ports which has certain parallels.
A separate fusion-specific attribute is also possible. If independent
of the scheduling type, it would not require pipeline model changes and
could provide more precise initial filtering for recurring
single-instruction classes. However, it still could not describe
dependencies between the pair, register relationships, modes, or
immediate constraints, so it would not replace the RTL checks. Also,
one instruction can participate in several fusions in different
positions, which is awkward for a single enum attribute. Every
equivalent MD pattern would also need to maintain the attribute, or
fusions could be silently missed.
Right. It would be mostly to avoid custom RTL recognition. It's not
really going to tackle the dependency problems at all.
I therefore currently lean toward keeping a fusion-specific attribute
as an option rather than introducing one in this series. For now, using
the existing insn type as an initial filter and shared helpers for exact
RTL and constraint checks seems simpler. A separate attribute might be
more appropriate if several matchers later need the same finer
classification.
However, this is only my current understanding. I am not sure whether
this assessment is correct or reasonable, or whether it fits the
preferred long-term GCC design. Could you provide further guidance on
whether we should split the existing insn types, add a separate fusion
attribute, or continue with the current combination of types and RTL
helpers? Any other comments would also be very welcome.
I think you're assessment is quite reasoanble & correct. Thanks for the
insights.
jeff
