On 7/6/24 07:20, Jeff Law wrote:


On 7/3/24 3:16 PM, Patrick O'Neill wrote:
Regarding the amocas.q follow-up patch:

I'm having trouble with matching any TImode compare-and-swap patterns. Here's the RTL I'm trying:

(define_mode_iterator SUPERGPR [SI DI TI])

(define_insn "zacas_atomic_cas_value<mode>"
   [(set (match_operand:SUPERGPR 0 "register_operand" "=&r")
     (match_operand:SUPERGPR 1 "memory_operand" "+A"))
    (set (match_dup 1)
     (unspec_volatile:SUPERGPR [(match_operand:SUPERGPR 2 "reg_or_0_operand" "rJ")
                    (match_operand:SUPERGPR 3 "reg_or_0_operand" "rJ")
                    (match_operand:SI 4 "const_int_operand")  ;; mod_s
                    (match_operand:SI 5 "const_int_operand")] ;; mod_f
I'd check if it's the mode on operands 4 and 5.  CONST_INTs do not have modes.

I gave it a shot with no dice. Same behavior where SI/DI mode match but TImode falls over.

https://gcc.gnu.org/onlinedocs/gccint/Machine-Independent-Predicates.html

| Function: const_int_operand
|     This predicate allows any CONST_INT expression that fits in mode. It is an appropriate choice for an immediate operand that does not allow a symbol or label.

If I'm reading this right the const_int mode constrains the const_int to a given mode. Not super relevant here since mod_s/mod_f is a 6 state enum but it looks like const_int is at least aware of the mode?


{
   emit_insn (gen_zacas_atomic_cas_value<mode> (operands[1], operands[2],
                            operands[3], operands[4],
                            operands[6], operands[7]));
Don't you need to pass operands[1] twice?  Once for operands[0] in the final pattern, then again for operands[1] in that final pattern?

I don't think so - operands[1] is a register while operands[2] is the memory location.

expand pattern           insn pattern
operands[1] register  -> operands[0] register "=&r"
operands[2] memory    -> operands[1] memory "+A"
operands[3] reg_0     -> operands[2] reg_0 "rJ"
operands[4] reg_0     -> operands[3] reg_0 "rJ"
operands[6] const_int -> operands[4] const_int
operands[7] const_int -> operands[5] const_int

Thanks for taking a look - I'll spend some time digging into insn-recog.cc to get to the bottom of this.

Patrick

jeff

Reply via email to