alexey-bataev wrote: > Personally I'm happy with keeping this nuance outside of TTI but if we really > want this captured within TTI then I think it's time to break FREM into its > own cost function (i.e. implement getFRemInstrCost. That way > getArithmeticInstrCost can work as it does today and the new function can be > documented to highlight it's assumption that if a TLI is passed in and a > vector mapping is present then the return value is only valid based on it's > assumption that vector FREM instructions will be transformed by a following > transformation pass. I prefer this to say, adding TLI to > getArithmeticInstrCost, because I'd rather users of getFRemInstrCost to > explicitly enter into this contract.
Hm, not sure adding getFRemInstrCost is the best solution here. I would more support adding TLI to getArithmeticInstrCost instead. Some other users may benefit from this too. Though getFRemInstrCost is still better than the current solution https://github.com/llvm/llvm-project/pull/82488 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
