<div dir="ltr">At this point, I'm not really seeing the benefit of this patch.<div><br></div><div>It takes 2 structs and 2 functions, both of which are dead simple, and replaces them with 3 class templates in an inheritance tree plus an inner struct a constructor and one function that is significantly more complex. It doesn't make things more efficient in the process. It doesn't really make this a generic tool for table lookup, because the tables are not in fact generic. I think ultimately I would prefer the original code here. Maybe there is a massive simplification this provides to some future code you're considering that I don't see yet? Dunno...</div>
<div><br></div><div><br></div><div style>Sorry for being a bit of a rain cloud here. To try to give some constructive ideas, I looked at the fundamental problem, and I see two designs that seem more workable:<br></div><div style>
<br></div><div style>1) A TargetCostTable class template in include/llvm/Target which accepts a T type parameter that can be either MVT, std::pair<MVT, MVT>, or std::tuple<MVT, MVT, ...>. Then the ISD and the cost value can be concrete things.</div>
<div style><br></div><div style>2) Teach tablegen to produce pre-sorted tables with lookup routines from a .td file in the target.</div><div style><br></div><div style>My suspicion is that #1 will end up being nearly as much code and complexity as the duplication between ARM and X86....</div>
<div style><br></div><div style>My suspicion is that *if* it is worth abstracting this stuff, we should just do #2 and make it really powerful. Then we can quickly build very large and detailed cost tables, and they will remain efficient and simple to use in each target.</div>
</div>