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
