[RISC-V] Update SpacemiT X60 vector scheduling model with measured latencies

[mikhailramalho]

Updates the SpacemiT X60 scheduling model with actual latencies measured on BPi-F3 hardware.

tl;dr: execution time is neutral on SPEC after this patch. There is a code size regression described in issue #146407

Changes:

• Added 10 new latency classes
• Updated latencies for ~30 instruction categories based on hardware measurements

Completed:

• Basic integer ALU, min/max, saturating/averaging arithmetic
• Carry operations, mask operations, comparisons
• Integer/FP division (split simple/complex based on LMUL)
• Widening operations
• FP operations including add/sub, mul, FMA
• FP conversions (widening/narrowing)
• FP reductions including vfredmax/min/usum (fixed fractional LMUL latencies)
• FP ordered reductions vfredosum (split simple/complex)
• FP widening reductions vfwredosum/vfwredusum (split simple/complex)
• Integer reductions
• Mask manipulation operations
• Permutation operations (gather/compress/slide)
• Narrowing shifts and clips (split simple/complex)

Missing:

• All vector loads/stores uops are missing their actual latency values. The values in this PR are estimations, while I'm still collecting the real numbers

Performance Impact:

• https://lnt.lukelau.me/db_default/v4/nts/674?compare_to=673
• This change is mostly NFC
• The two benchmarks with improvement/regression on execution time are known to be noisy
• There is an increase in code size in two benchmarks: reviewing the code changes, we see a lot more vector load/store instructions

Known Issues:

• Code size regression on two SPEC benchmarks
• Some operations grouped use worst-case latency
• TableGen !cond expressions not working as expected for vector single-width FMA instructions
• All compromises I've made are documented as TODO in the code

Planned follow-up PRs:

• Debug the code size regressions
• Add latencies for vector loads/stores
• Work on the TODOs introduced by this PR. It should require splitting some WriteRes groups and changing other scheduling models, but it should be NFC for them

[mshockwave]

Personally I kind of agree that we can make multiplication's SchedWrite SEW-dependant

[preames]

Hm, this seems backwards from what I expect with larger EEWs being more expensive? I would expect this to scale with the number of elements, and thus have smaller EEWs be more expensive.

[preames]

These don't seem right. I'd expect either LD + shuffle costing, or one-per-element costing.

[preames]

Some of these have ReleaseAtCycle, and some don't, but I don't see any obvious pattern? Am I missing something here?

[preames]

I talked w/Mikhail offline. I'm generally happy with the direction of this overall patch, but we need to split off smaller pieces to make them practically reviewable. Mikhail is going to post a much smaller patch, starting with the simple integer instructions. I plan to iterate back and forth with him quickly on the patch series with quick LGTMs on the sub-parts where possible for the "obvious" stuff. We'll slow down once we get to the harder parts, so we can focus attention on the interesting questions.