On 7/8/2026 6:07 AM, 翁丽琴 wrote:
It can't be included in GCC until binutils is updated.
Given the nature
of this capability it may be necessary to conditionalize using this
capability based on whether or not the assembler has the proper
support.
Is it necessary to add an option for control optimization? Or do you
have any ideas?
It's not about control of the optimization, but more about can the
assembler handle the output of the compiler. The projects release on
independent schedules and it's possible for someone to have an updated
compiler, but an out of date assembler. For a patch like yours the
compiler ends up emitting code the assembler can handle and the end user
is left with a failure they don't understand.
Given the relative newness of the RISC-V port we have let these problems
slide by for a while, but we're at the point where we need to pay
attention to this kind of issue.
There are many tests for the assembler's capabilities in the GCC sources
already that you could use as a starting point. Search for HAVE_GAS_*
for those examples.
> +(define_insn "base_idx_shxadd<X:MODE>"
> + [(set (match_operand:X 0 "register_operand" "=r")
> + (unspec:X
> + [(ashift:X (match_operand:X 1 "register_operand" "r")
> + (match_operand:QI 2 "imm123_operand" "Ds3"))
> + (match_operand:X 3 "register_operand" "r")
> + (match_operand:X 4 "symbolic_operand" "")]
> + UNSPEC_BASE_IDX_ADD))]
> + "TARGET_ZBA"
> + "sh%2add\t%0,%1,%3,%%base_idx_add(%4)"
> + [(set_attr "type" "bitmanip")
> + (set_attr "mode" "<X:MODE>")])
We really shouldn't need to be using UNSPECs here. It's also
unclear
to me what the assembler & linker are going to do with this 4-operand
shadd. If it's going to expand to multiple instructions, then you're
going to need to adjust the length attribute. Similarly for the
4-operand add you created in riscv.md <http://riscv.md>.
I have forwarded the implementation of binutils to you. If possible,
please help review it.
The better thing to do is explain how this new form of an shadd
instruction works. It looks like it's got 4 operands now, which doesn't
make sense to me. ANd again, I strongly suspect you should not be using
UNSPECs here. UNSPECS are to be used when its exceedingly hard to
describe the underlying semantics. All this looks like is a variant of
shNadd which can be easily expressed in RTL.
In your .cc file, you've introduced a whole new pass to create these
things. Please look closely at other code and try to avoid adding
another pass if it can be avoided. In many ways this reminds me a
lot
of fold-mem-offsets, so you might want to look closely at that pass
In fact, I also tried to do it in several stages, such as：RTL Expand/
COMBINE/fold-mem-offsets.cc <http://fold-mem-offsets.cc>， However, the
changes were rather cumbersome and complex, so I finally decided to
extract them separately for optimization.
That's fine for development, but I'd like to understand the core
problems with discovering during combine or fold-mem-offsets. IT's
often easy to model something as a distinct pass, but we try to avoid
adding passes when existing ones can be relatively easily extended. I
haven't seen any discussion about why it was overly cumbersome and
complex. You'd need to explain that.
If you're going to ultimately need a new pass, then it needs to
follow
coding styles and guidelines. The formatting/style is *way* off
in that
new pass. It's bad enough that I didn't really dive into the basic
implementation details. It's also worth noting that your mailer
seems
to be double-spacing everything making the patch exceptionally
hard to read.
Sorry, as a new GCC developer, I'm learning the GNU style. Do you have
any good recommended tools? I use the command: `git diff -U0
--no-color --cached HEAD | clang-format-diff -p1 -i`, but it formats
some code that I haven't modified.
I believe there is a clang-format setting in the contrib subdirectory.
I don't personally use it, but I believe others do and it may help, even
if it's not 100% correct.
https://gcc.gnu.org/contribute.html#standards
Jeff
