similar to: TargetTransformInfo getOperationCost uses

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

CostModule::getInstructionCost also consults TTI ( http://llvm.org/docs/doxygen/html/CostModel_8cpp_source.html#l00380). No? Jingyue On Wed, Jan 14, 2015 at 4:05 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Jan 14, 2015 at 3:54 PM, Jingyue Wu <jingyue at google.com> wrote: > >> I'm looking for APIs that compute instruction costs, and noticed

On Mon, Sep 30, 2019 at 11:52 AM Joan Lluch <joan.lluch at icloud.com> wrote: > > Hi Roman, > > Is "test" actually an implementation of a 64-bit-wide multiplication > compiler-rt builtin? > Then i'd think the main problem is that it is being optimized in the > first place, you could end up with endless recursion… > > > No, this is not a compiler-rt

For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp or InstCombiner::transformZExtICmp ~Craig On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <support at sweetwilliamsl.com> wrote: > Hi all, > > Ok, I just found a much simpler example of the same issue. > > Consider the following code > > int cmpge32_0(long a) { > return a>=0; > } >

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

Hi, I ran into this issue recently and wanted to know if it was a bug or expected behavior. In the R600 backend's TargetTransformInfo implementation, we were setting UnrollingPreferences::Count = UINT_MAX. This was a mistake as we should have been setting UnrollingPreferences::MaxCount instead. However, as a result of setting Count to UINT_MAX, this loop would be unrolled 15 times: if (b

> On Mar 10, 2016, at 10:34 AM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Mar 10, 2016 at 6:49 AM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: > 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

I know, I said a bad word -- analysis group. But it works pretty much the way I think we want here. We *always* want a TargetTransformInfo, and we have reasonable (conservative) stubs in place. We would just like the option of providing one from the target that has very clever implementations. I would propose that we make TargetTransformInfo be an analysis group, and provide

Hi Sanjay, Thanks for your reply. > So yes, the IR optimizer (instcombine is the specific pass) sometimes turns icmp (and select) sequences into ALU ops. Instcombine is almost entirely *target-independent* and should remain that way. The (sometimes unfortunate) decision to create shifts were made based on popular targets of the time (PowerPC and/or x86), and other targets may have suffered

On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sanjay, > > Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental. > > For targets that actually have selects, but branches

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, "Jingyue Wu" <jingyue at google.com> > Sent: Wednesday, July 1, 2015 2:27:59 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > >

Hi, We've a target which has hardware support for zero-overhead loops. Currently, we cannot detect them because the loop unroller is unrolling them before entering into the codegen. Looking at its implementation, it seems that it checks if it is profitable to unroll it or not based on certain parameters. Given that zero cost loops building is based more or less on the same constraints

Dear LLVM contributors, I work on the "Improvement of vectorization process in Polly". At the moment I'm trying to implement tiling, interchanging and unrolling of specific loops based on the following algorithm for the analytical modeling [1]. It requires information about the following parameters of a target architecture: 1. Size of double-precision floating-point number. 2.

Hi Hal, On 21/11/2012 22:38, Hal Finkel wrote: > ----- Original Message ----- >> From: "Ivan Llopard" <ivanllopard at gmail.com> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Wednesday, November 21, 2012 10:31:07 AM >> Subject: [LLVMdev] Disable loop unroll pass >> >> Hi, >> >> We've a

Hi Shuxin, Eli, On 22/11/2012 03:19, Shuxin Yang wrote: > Hi, Ivan: > > My $0.02. hasZeroCostLooping() disabling unrolling dose not seem > to be > appropriate for other architectures, at least the one I worked before. I appreciate your feed-back. Could you give an example where building a hw loop is not appropriate for your target? > > You mentioned: >

Hi, Ivan: My $0.02. hasZeroCostLooping() disabling unrolling dose not seem to be appropriate for other architectures, at least the one I worked before. You mentioned: >Currently, we cannot detect them because the loop unroller is >unrolling them before entering into the codegen. Looking at its implementation, >it. Could you please articulate why CG fail to recognize it?

I personally strong abhor this kind of thing:-) I guess I should be more open-minded. For pre-ipo phase, some passes should not invoke, say, any loop nest-opt, loop version, aggressive loop unrolling, vectorization, aggressive inling. The reasons are they will hinder the downstream optimizers if they kick in early. > Out of curiosity, has anyone tried to optimize the pass ordering in some

----- Original Message ----- > From: "Ivan Llopard" <ivanllopard at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, November 21, 2012 10:31:07 AM > Subject: [LLVMdev] Disable loop unroll pass > > Hi, > > We've a target which has hardware support for zero-overhead loops. > Currently, we

I am starting to use the sample profiler to analyze new performance opportunities. The loop unroller has popped up in several of the benchmarks I'm running. In particular, libquantum. There is a ~12% opportunity when the runtime unroller is triggered. This helps functions like quantum_sigma_x (http://sourcecodebrowser.com/libquantum/0.2.4/gates_8c_source.html#l00149). The function accounts

On 16/01/2014, 23:47 , Andrew Trick wrote: > > On Jan 15, 2014, at 4:13 PM, Diego Novillo <dnovillo at google.com > <mailto:dnovillo at google.com>> wrote: > >> Chandler also pointed me at the vectorizer, which has its own >> unroller. However, the vectorizer only unrolls enough to serve the >> target, it's not as general as the runtime-triggered