llvm / llvm/llvm-project

[RISCV] RISCVTTIImpl::getArithmeticInstrCost() doesn't support scalar types

Open
#175,826 8 comments 0 reactions 1 assignee Claimed by @bababuck View on GitHub
backend:RISC-V
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.