| Issue |
175826
|
| Summary |
[RISCV] RISCVTTIImpl::getArithmeticInstrCost() doesn't support scalar types
|
| Labels |
new issue
|
| Assignees |
bababuck
|
| Reporter |
bababuck
|
Looking at \`RISCVTTIImpl::getArithmeticInstrCost()\`, there is `// TODO: Handle scalar type` . Currently we just rely on the default to the base model for scalar cases.
I'm hoping to move to using a subtarget aware implementation so that we can set costs accurately for different subtargets. I was hoping to gather some input on where best to store this information. A couple options for this:
1. Embed cost information directly within \`getArithmeticInstrCost()\`, this seems to be what the `x86` backend is doing, see `lib/Target/X86/X86TargetTransformInfo.cpp::1463`
```
static const CostKindTblEntry X86CostTbl[] = { // 32 or 64-bit targets
{ ISD::ADD, MVT::i8, { 1 } }, // Pentium III from http://www.agner.org/
{ ISD::ADD, MVT::i16, { 1 } }, // Pentium III from http://www.agner.org/
{ ISD::ADD, MVT::i32, { 1 } }, // Pentium III from http://www.agner.org/
...
```
2. Add this information into \`RISCVProcessors.td::RISCVTuneInfo\` (or a similar new structure)
3. Plumb in this information from the schedule model at runtime. We already have `MCSchedModel::getReciprocalThroughput()` and `MCSchedModel::computeInstrLatency` , so could re-use those or add something similar.
4. Generate a structure from the scheduling model at compiler compile time. Benefit of not having duplicated information, and also no extra overhead at runtime of expensive calls to `MCSchedModel`.
My intuition is that we should use option (2) because of ease of implementation and then also even though we will be duplicating information (since this information is already somewhat contained in the scheduling model), we probably will want to be able to fudge these values separately from the scheduling model.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
