Re: [PATCH 1/3][RFC] RISC-V: Add non-vector types to pipelines

[Jeff Law <jeffreyalaw@gmail.com>]

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