The cost of immediates returned from the backend was generally wrong, returning 1 for most immediates that could be directly encoded within an instruction. We now return 0 for these. The valuesreturned are now also more accurate, taking into consideration the exotic encoding patterns of Thumb2 immediates and calculating how many mov instructions would be needed to rematerialise a value.
Details
Diff Detail
Event Timeline
It looks like APInt doesn't function the way I expected, nor in the way that the other authors of this area would have expected. I've posted a query: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129781.html
lib/Target/ARM/ARMTargetTransformInfo.cpp | ||
---|---|---|
111 | Can we have a enum or so with these return constants and use them instead of “return 3”, “return 1”, .. |
lib/Target/ARM/ARMTargetTransformInfo.cpp | ||
---|---|---|
111 | Sure, I'll use TargetCostConstants. |
lib/Target/ARM/ARMTargetTransformInfo.cpp | ||
---|---|---|
99 | Why are you throwing away the existing code using getT2SOImmVal/getSOImmVal and writing out the same logic inline? | |
108 | Should this be guarded by useMovt? | |
158 | Not sure I follow this logic; what does "Imm" actually mean in this case? Are we expecting that the result of the GEP will be folded into a load? |
Actually, we already have some very similar code in ARMDAGToDAGISel::ConstantMaterializationCost; can we share that code somehow?
I like that idea, I think moving the logic into ARMISelLowering would be good as we already use similar logic there too.
lib/Target/ARM/ARMTargetTransformInfo.cpp | ||
---|---|---|
99 | Thanks, I'll revert. | |
108 | Will do. | |
158 | Yes, I'm assuming an immediate index which will be directly used by a load/store. I know this assumption doesn't hold all the time... But I'm not sure what to do with the limited information here. |
Why are you throwing away the existing code using getT2SOImmVal/getSOImmVal and writing out the same logic inline?