Home Original page

[PATCH v2] RISC-V: Add support for 'Zacas' atomic CAS

Jan Beulich jbeulich@suse.com
Wed Oct 25 06:02:02 GMT 2023 
On 25.10.2023 04:15, Nelson Chu wrote:
> On Tue, Oct 24, 2023 at 2:03 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> On 24.10.2023 06:07, Tsukasa OI wrote:
>>> As a single patch set, I think Gianluca's patch with a minor fix will
>>> work perfectly.  But, the concept of register pairs / register groups
>>> are not specific to 'Zacas', that's what I'm talking about and the
>>> reason I think Gianluca's patch set's match function will not be a long
>>> term solution (actually, I found Gianluca's patch set after I wrote
>>> mine, but that wouldn't change my opinion).
>>
> 
> As I said before, I don't know if we really need the constraint checks for
> register groups in assembler or not.  Or on the other hand, I don't know if
> we really need the detailed register constraint checks for assembly
> syntax.  I remembered you completely unacceptable to fight back that you
> don't care about hardware testing since you were doing toolchain, but for
> those DV guys, they are also one of the users of toolchain.  However, for
> many things, lots of users are used to using some behaviors or code in the
> toolchain.  These behaviors are not wrong, maybe they are just not that
> rigorous.  Even though your idea may be beneficial to some people, it can
> also cause problems for others.
> 
> So, I was not rejecting your idea before, I was just trying to let you know
> every change you made may cause trouble for others, especially that some
> behaviors are established for many years.  Since the rvv register group
> checks were argued before and removed, I will suggest we just
> remove the same checks for zacas.  If other maintainers support that we
> should also do these kinds of complicated constraint checks, then you can
> ignore my comments.

First, despite being sent To: me, I assume your reply was targeted at
Tsukasa?

Irrespective, while I'm not a RISC-V maintainer, I'd like to advocate in
favor of these checks (uniformly wherever applicable). If they pose
problems to certain people, let's have a command line option to suppress
them. (To some degree these checks are related to a remark towards hint
insns that I had raised quite some time ago: When doing things really
strictly, I continue to be of the opinion that those should only ever be
expressed as "hint", with their non-hint forms - e.g. some kind of ALU
insn with x0 as destination - at least warned about. The main issue
there obviously is how to pick among the many hint forms with just a
single "hint" mnemonic.)

Jan
More information about the Binutils mailing list