If the generic cost model, based on DataLayout, says that a cast is free then return zero. Otherwise we now return the cost provided by getCastInstrCost.
Details
Diff Detail
Unit Tests
Event Timeline
llvm/test/Analysis/CostModel/X86/size-cost.ll | ||
---|---|---|
33 | Let me know if I'm missing larger context, but this is not correct. A cast from xmm <-> gpr ("movq %xmm0, %rax") is not free in any sense on any x86 target AFAIK. Do we need to fix the x86 override as a preliminary step? |
llvm/test/Analysis/CostModel/X86/size-cost.ll | ||
---|---|---|
33 | I didn't expect it to be correct.. I'm happy to look into the fix. |
llvm/test/Analysis/CostModel/X86/size-cost.ll | ||
---|---|---|
33 | Sounds good - thanks! |
Actually, let me take a step back: we're saying that getCastInstrCost() is a code-size query? Is that what the current callers are assuming? Do we need to invent a new API that makes it explicit that we are modeling size cost?
llvm/test/Analysis/CostModel/X86/size-cost.ll | ||
---|---|---|
33 | Is it thought? Note that we test *size* cost here. |
llvm/test/Analysis/CostModel/X86/size-cost.ll | ||
---|---|---|
33 | I was assuming this and the other test requires one of: movq %xmm0, %rax movq %rax, %xmm0 |
Actually, let me take a step back: we're saying that getCastInstrCost() is a code-size query? Is that what the current callers are assuming? Do we need to invent a new API that makes it explicit that we are modeling size cost?
getUserCost is called for code size, but it's not explicitly code-size only, I believe it was designed around the vague notion of hybrid of size and performance which the 'TargetCostConstants' describe and this is the same for getCastInstrCost. I'd like to change these methods to take a TargetCostKind argument so that we can end this ambiguity. It would also allow removal of the 'getInstructionLatency' stuff as it only used in one place and has no backend implementation.
This now looks like an NFC with the bitcasts fixed, but I strongly suspect that some backends will need tweaking when D78922 is in too.
Let me know if I'm missing larger context, but this is not correct. A cast from xmm <-> gpr ("movq %xmm0, %rax") is not free in any sense on any x86 target AFAIK.
Do we need to fix the x86 override as a preliminary step?