On 12/20/23 15:11, Edwin Lu wrote:



  (define_insn_reservation "generic_xfer" 3
    (and (eq_attr "tune" "generic")
-       (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp"))
+       (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp,cbo"))
    "alu")
cbo is probably closer to a load/store than it is a transfer operation.

That makes sense. I wasn't sure where exactly to put it since we have two separate insn reservations for load and store and from my understanding, the same type cannot be in two separate insn reservations. Would a new insn reservation like
(define_insn_reservation "generic_load_store" 2 ...) work?
I'd probably just treat cbo instructions as stores. In fact, you could probably get away with using "store" as the type and dropping the cbo type entirely.





  (define_insn_reservation "generic_branch" 1
    (and (eq_attr "tune" "generic")
-       (eq_attr "type" "branch,jump,call,jalr"))
+       (eq_attr "type" "branch,jump,call,jalr,ret,trap,pushpop"))
+  "alu")
pushpop are a mix of some pure memory operations and some mixed memory + branch.

However, from a scheduling standpoint the branch isn't particularly interesting.  So I'd have pushpop as a load/store.
So for these I think those which do pushes you could legitimately change to the "store" type and pops could be changed to a "load" type. If something does both just call it a load. That's going to be the most useful from a scheduling standpoint I suspect.



Jeff

Reply via email to