[all-commits] [llvm/llvm-project] 458468: [CostModel][X86] Support cost kind specific look u...

[Simon Pilgrim via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 45846854a2c1414c27bc819033f6de588dea56fe
      https://github.com/llvm/llvm-project/commit/45846854a2c1414c27bc819033f6de588dea56fe
  Author: Simon Pilgrim <llvm-dev at redking.me.uk>
  Date:   2022-08-25 (Thu, 25 Aug 2022)

  Changed paths:
    M llvm/lib/Target/X86/X86TargetTransformInfo.cpp
    M llvm/test/Analysis/CostModel/X86/intrinsic-cost-kinds.ll
    M llvm/test/Analysis/CostModel/X86/select-codesize.ll
    M llvm/test/Analysis/CostModel/X86/select-latency.ll
    M llvm/test/Analysis/CostModel/X86/select-sizelatency.ll
    M llvm/test/Transforms/PhaseOrdering/X86/vector-reductions-logical.ll

  Log Message:
  -----------
  [CostModel][X86] Support cost kind specific look up tables

Most of our cost model tables have been created assuming cost kind == recip-throughput. But we're starting to see passes wanting to get accurate costs for the other kinds as well. Some of these can be determined procedurally (e.g. codesize by default could just be the split count after type legalization), but others are going to need to be handled in cost tables - this is especially true for x86 which has so many ISA combinations.

I've created a 'CostKindCosts' struct which can hold cost values for the 4 cost kinds, defaulting to -1U for unknown cost, this can be used with the existing CostTblEntryT/CostTableLookup template code. I've also added a [TargetCostKind] accessor to make it much easier to look up individual <Optional> costs.

This just changes the ISD::SELECT costs to check the effect (and also to check that the ISD::SETCC are correctly handled for default/None cost kinds) - the plan would be to slowly extend this and move the CostKindTblEntry type somewhere generic to allow other targets to use it once its matured.

I'm also going to resurrect D103695 so that it can help with latency/codesize/sizelatency coverage testing.

For sizelatency - IIRC the definition was vague to let it be target specific - I've tried to use typical uop counts so they're comparable to MicroOpBufferSize etc.

Differential Revision: https://reviews.llvm.org/D132216