Re: [PATCH v2] RISC-V: Add basic support for the Zacas extension

[Jeff Law]

On 7/23/24 6:39 PM, Patrick O'Neill wrote:
  (define_expand "atomic_compare_and_swap<mode>"
    [(match_operand:SI 0 "register_operand" "")   ;; bool output
     (match_operand:GPR 1 "register_operand" "")  ;; val output
     (match_operand:GPR 2 "memory_operand" "")    ;; memory
-   (match_operand:GPR 3 "reg_or_0_operand" "")  ;; expected value
+   (match_operand:GPR 3 "register_operand" "")  ;; expected value
     (match_operand:GPR 4 "reg_or_0_operand" "")  ;; desired value
     (match_operand:SI 5 "const_int_operand" "")  ;; is_weak
     (match_operand:SI 6 "const_int_operand" "")  ;; mod_s
     (match_operand:SI 7 "const_int_operand" "")] ;; mod_f
<snip>
-(define_expand "atomic_cas_value_strong<mode>"
+(define_expand "zalrsc_atomic_cas_value_strong<mode>"
    [(match_operand:SHORT 0 "register_operand") ;; val output
     (match_operand:SHORT 1 "memory_operand")   ;; memory
     (match_operand:SHORT 2 "reg_or_0_operand") ;; expected value

Wanted to highlight this for reviewers since it's non-obvious when
reading the diff:
`expected value` is now a `register_operand` since that's needed for
amocas as it reads/writes expected/actual value to the same register.

I left the zalrsc pattern as `reg_or_0_operand` even though it will
only be passed `register_operand` from the expander.
I think it captures the lr/sc pattern's requirements better but I'm
happy to change this if register_operand is preferred for the zalrsc case.
No strong opinion.  Clearly we have to use register_operand if it's 
in/out.  As for pure inputs, using reg_or_0_operand  is on the margins 
for something like this.


Jeff