This adds new function getMemcpyCost to TTI so that the cost of a memcpy can be
modeled and queried.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/llvm/Analysis/TargetTransformInfoImpl.h | ||
---|---|---|
144 ↗ | (On Diff #190249) | That seems optimistic, even as a default. I'd probably bump it to TCC_Expensive if just one load/store is needed, and a size-based estimate would be even better (is there a DataLayout handy to calculate length in terms of pointer-words?) |
include/llvm/Analysis/TargetTransformInfoImpl.h | ||
---|---|---|
144 ↗ | (On Diff #190249) | Thanks for looking into this. Agreed that TCC_Basic doesn't make much sense. As a default size based estimate, I am thinking of this default: (2 * TCC_Basic) * (memcpy-count / pointer-size) where: Since this will change behaviour, I probably need a test somewhere. :-) |
include/llvm/Analysis/TargetTransformInfoImpl.h | ||
---|---|---|
144 ↗ | (On Diff #190249) | A pointer size isn't relevant. We already have things like getMemcpyLoopLoweringType for when memcpy is expanded. The cost should also be much higher for unknown amounts |
In my previous comment, I commented on a possible default cost calculation for a memcpy, which approximated the cost by calculating the number of load/stores pairs. I probably could see this working as a default estimation, because I think when this would be used, the result will be that memcpy's are considered expensive relative to other instructions, which is probably correct. However, I appreciate that this is an approximation, and that there are many things missing here, like source/destination alignment, available load/store instruction, etc., which really shows this is a target dependent decision. So, I've changed getMemcpyCost to just simply return TCC_Expensive, so that target can override this method and implement their decision making there, like is done for many/most functions here in TTI.
I've added a regression test.
Apologies for already asking, but I was curious if @t.p.northover or @arsenm had more feedback/concerns or if this looks somewhat reasonable.
LGTM. I think returning Expensive is the only reasonable thing we can do for a default implementation. It's more realistic than Basic and for anything else more complicated, it should be up to a target to override.
Thanks for looking Sam!
I will wait a day with committing this, just in case there are more comments.