Open
Description
We have a large number of old exegesis samples, which often have bitrotted due to changes in instruction naming over the years:
---
mode: uops
key:
instructions:
- 'VADDPDYrrr YMM2 YMM13 YMM9'
config: ''
register_initial_values:
- 'YMM13=0x0'
- 'YMM9=0x0'
- 'MXCSR=0x0'
cpu_name: znver1
llvm_triple: x86_64-unknown-linux-gnu
min_instructions: 10000
measurements:
- { key: ZnFPU0, value: 0, per_snippet_value: 0, validation_counters: {} }
- { key: ZnFPU1, value: 0, per_snippet_value: 0, validation_counters: {} }
- { key: ZnFPU2, value: 1.0013, per_snippet_value: 1.0013, validation_counters: {} }
- { key: ZnFPU3, value: 1.0018, per_snippet_value: 1.0018, validation_counters: {} }
- { key: ZnAGU, value: 0.0045, per_snippet_value: 0.0045, validation_counters: {} }
- { key: ZnDivider, value: 0, per_snippet_value: 0, validation_counters: {} }
- { key: NumMicroOps, value: 2.0087, per_snippet_value: 2.0087, validation_counters: {} }
error: ''
info: instruction has no tied variables, avoiding Read-After-Write issue, picking random def and use registers not aliasing each other, for uses, one unique register for each position
assembled_snippet: 4883EC20C7042400000000C744240400000000C744240800000000C744240C00000000C744241000000000C744241400000000C744241800000000C744241C00000000C57E6F2C244883C4204883EC20C7042400000000C744240400000000C744240800000000C744240C00000000C744241000000000C744241400000000C744241800000000C744241C00000000C57E6F0C244883C4204883EC04C70424801F0000C5F8AE14244883C404C4C11558D1C4C11558D1C4C11558D1C4C11558D1C3
...
---
mode: uops
key:
instructions:
- 'VADDPDrr XMM5 XMM12 XMM13'
config: ''
register_initial_values:
- 'XMM12=0x0'
- 'XMM13=0x0'
- 'MXCSR=0x0'
cpu_name: znver1
llvm_triple: x86_64-unknown-linux-gnu
min_instructions: 10000
measurements:
- { key: ZnFPU0, value: 0.0001, per_snippet_value: 0.0001, validation_counters: {} }
- { key: ZnFPU1, value: 0.0001, per_snippet_value: 0.0001, validation_counters: {} }
- { key: ZnFPU2, value: 0.4734, per_snippet_value: 0.4734, validation_counters: {} }
- { key: ZnFPU3, value: 0.484, per_snippet_value: 0.484, validation_counters: {} }
- { key: ZnAGU, value: 0.004, per_snippet_value: 0.004, validation_counters: {} }
- { key: ZnDivider, value: 0, per_snippet_value: 0, validation_counters: {} }
- { key: NumMicroOps, value: 1.0081, per_snippet_value: 1.0081, validation_counters: {} }
error: ''
info: instruction has no tied variables, avoiding Read-After-Write issue, picking random def and use registers not aliasing each other, for uses, one unique register for each position
assembled_snippet: 4883EC10C7042400000000C744240400000000C744240800000000C744240C00000000C57A6F24244883C4104883EC10C7042400000000C744240400000000C744240800000000C744240C00000000C57A6F2C244883C4104883EC04C70424801F0000C5F8AE14244883C404C4C11958EDC4C11958EDC4C11958EDC4C11958EDC3
...
E:\llvm>llvm-exegesis -mode=analysis -analysis-inconsistencies-output-file=uops-test.html -benchmarks-file=uops-test.yaml
using Triple 'x86_64-unknown-linux-gnu' and CPU 'znver1'
uops-test.yaml:5:7: error: No opcode with name 'VADDPDYrrr'
- 'VADDPDYrrr YMM2 YMM13 YMM9'
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
llvm-exegesis: 'uops-test.yaml': invalid **argument**
Instead of just reporting an error and stopping, it'd be very useful if the analysis warns about the unknown opcode entries (so we can edit the captures in our own time) and then continue, creating the output report for just the valid instruction entries.
If the warning could offer a suggestion for a known opcode name (No opcode with name 'VADDPDYrrr' - did you mean 'VADDPDYrr' ) that would be awesome.