search for: getusercost

...e the resulting value. And that is indeed the case in PR32964. How is this supposed to work? I started seeing this after the commit SpeculativeExecution: Stop using whitelist for costs Before that, e.g. a load got the cost UINT_MAX which I suppose disabled hoisting, but since the commit TTI.getUserCost(I) is used for all instructions. Regards, Mikael

Hi, I'd like to propose a change to our cost interfaces so that instead of returning an unsigned value from functions like getInstructionCost, getUserCost, etc., we instead return a wrapper class that encodes an integer cost along with extra state. The extra state can be used to express: 1. A cost as infinitely expensive in order to prevent certain optimisations taking place. For example, there are already examples in LLVM where the cost is set extr...

...ly reported by opt -cost-model -analyze (the actual cost model tests) seem to not matter for this. The huge cost I've assigned division doesn't prevent the loop from being unrolled, because it isn't actually considered when loop unrolling. The loop unrolled uses CodeMetrics, which via getUserCost ultimately uses TargetTransformInfoImplBase::getOperationCost(), which returns various fixed values (4 for division (TCC_Expensive, but this isn't nearly expensive enough)). getOperationCost only uses the type and opcode to estimate, so it doesn't require a value. No target overrides this...

...s.llvm.org<mailto:llvm-dev at lists.llvm.org> Subject: [EXT] [llvm-dev] [Proposal] Introducing the concept of invalid costs to the IR cost model Hi, I'd like to propose a change to our cost interfaces so that instead of returning an unsigned value from functions like getInstructionCost, getUserCost, etc., we instead return a wrapper class that encodes an integer cost along with extra state. The extra state can be used to express: 1. A cost as infinitely expensive in order to prevent certain optimisations taking place. For example, there are already examples in LLVM where the cost is set extr...

...mber 5, 2020 7:43 AM To: llvm-dev at lists.llvm.org Subject: [EXT] [llvm-dev] [Proposal] Introducing the concept of invalid costs to the IR cost model Hi, I'd like to propose a change to our cost interfaces so that instead of returning an unsigned value from functions like getInstructionCost, getUserCost, etc., we instead return a wrapper class that encodes an integer cost along with extra state. The extra state can be used to express: 1. A cost as infinitely expensive in order to prevent certain optimisations taking place. For example, there are already examples in LLVM where the cost is set extr...

...ts with high call costs) > 2) if not, but instead GPU users can tolerate large code growth, then it is better to this by adjusting the threshold -- perhaps have a user level option -finline-limit=? > > thanks, > > David > > > * some target dependent info may be used: TTI.getUserCost > > Does that make sense to you Hal? Based on that, it would really just be a scaling factor of the inline heuristics. Unsure of how to more scientifically express this construct. > > -Chandler > > On Thu, Mar 10, 2016 at 3:42 PM Hal Finkel via llvm-dev <llvm-dev at lists.l...

IMO, the appropriate thing for TTI to inform the inliner about is how costly the actual act of a "call" is likely to be. I would hope that this would only be used on targets where there is some really dramatic overhead of actually doing a function call such that the code size cost incurred by inlining is completely dwarfed by the improvements. GPUs are one of the few platforms that

IMO, a good inliner with a precise cost/benefit model will eventually need what Art is proposing here. Giving the function call overhead as an example. It depends on a couple of factors: 1) call/return instruction latency; 2) function epilogue/prologue; 3) calling convention (argument parsing, using registers or not, what register classes etc). All these factors depend on target information. If

...s.llvm.org<mailto:llvm-dev at lists.llvm.org> Subject: [EXT] [llvm-dev] [Proposal] Introducing the concept of invalid costs to the IR cost model Hi, I'd like to propose a change to our cost interfaces so that instead of returning an unsigned value from functions like getInstructionCost, getUserCost, etc., we instead return a wrapper class that encodes an integer cost along with extra state. The extra state can be used to express: 1. A cost as infinitely expensive in order to prevent certain optimisations taking place. For example, there are already examples in LLVM where the cost is set extr...

...2, and compare the cost with the scalar loop based on that. Thanks and Regards, Vineet On 2020-11-05 9:12 p.m., David Sherwood via llvm-dev wrote: Hi, I'd like to propose a change to our cost interfaces so that instead of returning an unsigned value from functions like getInstructionCost, getUserCost, etc., we instead return a wrapper class that encodes an integer cost along with extra state. The extra state can be used to express: 1. A cost as infinitely expensive in order to prevent certain optimisations taking place. For example, there are already examples in LLVM where the cost is set extr...

Hi, I'm looking for APIs that compute instruction costs, and noticed several of them. 1. A series of APIs of TargetTransformInfo that compute the cost of instructions of a particular type (e.g. getArithmeticInstrCost and getShuffleCost) 2. TargetTransformInfo::getOperationCost 3. CostModel::getInstructionCost::getInstructionCost in lib/Analysis/CostModel.cpp Only the first one is used