similar to: [LLVMdev] LLVM IR vectorized with opt but not through the API

Hi, Thank you for the information, So I'm now keeping the array as a pointer (i32*) but the vectorizer doesn't vectorize it . I've pasted the function code before and after optimization (and the list of optimization that I have activated) in this Gist : https://gist.github.com/maattd/7008683 Some "weird" fact of my LLVM code : * all variables (even the one used for the

On Wed, Oct 16, 2013 at 11:14:06AM -0400, Matthieu Dubet wrote: > Hi, > > Thank you for the information, > > So I'm now keeping the array as a pointer (i32*) but the vectorizer doesn't > vectorize it . > > I've pasted the function code before and after optimization (and the list > of optimization that I have activated) in this Gist : >

Hi, I'm creating a small function in LLVM which gets as a parameter an i32* (this function is called from C code) . However I know that this pointer is actually a C array of size 10 ( int[10] ). How can I tell LLVM to consider this i32* as an <10 x i32> (and thus get the performance improvements thanks to SIMD ..etc..) ? Thanks, Matthieu -------------- next part -------------- An

Both the SLP vectorizer and the Loop vectorizer support vectorizing pointers. The attached code looks like a candidate for the SLP-vectorizer. Can you run the SLP-vectorizer with the flag -mllvm -debug-only=SLP and attach the log ? I think that we are missing the pattern for the roots of the tree. Thanks, Nadav On Oct 16, 2013, at 5:28 PM, Tom Stellard <tom at stellard.net> wrote: >

On 11 October 2013 18:27, Matthieu Dubet <maattdd at gmail.com> wrote: > How can I tell LLVM to consider this i32* as an <10 x i32> (and thus get > the performance improvements thanks to SIMD ..etc..) ? > Hi Matthieu, You shouldn't need to do anything, the vectorizer should spot that for you, if the machine you're compiling to has support for vector instructions.

If what you are saying is that you know the array of i32 will always be 10 entries, make the function use a constant limit=10 to the loop. I.e Make the loop limit a constant and not a variable. On 11 October 2013 18:27, Matthieu Dubet <maattdd at gmail.com> wrote: > Hi, > > I'm creating a small function in LLVM which gets as a parameter an i32* > (this function is called

I see the BackendUtil.cpp of Clang creates the TargetMachine with the optimization level based on below mentioned logic CodeGenOpt::Level OptLevel = CodeGenOpt::Default; switch (CodeGenOpts.OptimizationLevel) { default: break; case 0: OptLevel = CodeGenOpt::None; break; case 3: OptLevel = CodeGenOpt::Aggressive; break; } As per my understanding, the correspondence between

Here is a problem scenario. I want to enable a backend pass at -O2 or above. if (TM->getOptLevel() >= CodeGenOpt::Default) addPass(&xxxxx); This pass will be run at -O1 too since clang is creating the TargetMachine with CodeGenOpt::Default for -O1. --Sumanth G -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Friday, January 6, 2017

I want the optimization to be turned on at -O1 and above. In my case, it is a target independent back-end pass. (Eg: MachinePipeliner) On 2017-01-04 18:10, Mehdi Amini wrote: >> On Jan 4, 2017, at 4:03 PM, Sumanth Gundapaneni via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> I see the BackendUtil.cpp of Clang creates the TargetMachine with >> the

getOptLevel() gets the level from TargetMachine which is created by the Backendutil in clang with either "Default", "None" or "Aggressive". Threre is no correspondence for "Less". This boils down to , if I pass "-O1", the Target Machine is created with CodeGenOpt::Default. I am available on IRC @ sgundapa. -----Original Message----- From:

Chris Lattner <clattner at apple.com> writes: >> class CodeGenOpt { >> ... >> public >> getOptLevel() ...; >> getFPLevel() ...; >> getMemLevel() ...; >> }; >> >> Does this sound reasonable? > > I don't think that this is the right way to go. Higher level > decisions like that should affect your choice of passes to

Hi Lang, On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote: > When you say your code is not getting optimized, do you mean that IR optimizations are not being applied, or that codegen optimizations are not being applied? > > What do you see if you dump the modules before/after running the pass manager on them, like this: > > dbgs() << "Before

The existing CodeGenOpt is not flexible enough for our needs. Our customers want to be able to control the optimization level at a fine grain, so we provide them separate dials for general optimization, fp optimization and memory hierarchy optimization. I would like to replace the existing CodeGenOpt::Level enum with a more general CodeGenOpt class that can track different sets of optimization

Sorry in advance for the stupid question, i still don’t understand some concepts like passes. I took a piece of code from llc, and I used it to write a function that creates an object (or assembly) file from an IR module. It compiles without any problems. But program crashes when it reaches add() method of the pass manager. Can you help me figuring out what’s the problem please? here is my

On Feb 24, 2011, at 8:14 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: > >>> class CodeGenOpt { >>> ... >>> public >>> getOptLevel() ...; >>> getFPLevel() ...; >>> getMemLevel() ...; >>> }; >>> >>> Does this sound reasonable? >> >> I don't think that this is

The stack trace: llvm::PMTopLevelManager::addImmutablePass(llvm::ImmutablePass*) llvm::PMTopLevelManager::schedulePass(llvm::Pass*) moduleToObjectFile(llvm::Module*,std::string&,llvm::LLVMContext&) Sometimes it doesn't crash because TargetRegistry::lookupTarget() returns an error which says it doesn't support the current target > On Mar 24, 2016, at 1:14 AM, Mehdi Amini

Sorry, that's a pure crash I think, assertions are not triggered. Xcode doesn’t map those 2 functions to line numbers because they’re in precompiled libraries On Mar 24, 2016, at 1:44 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Mar 23, 2016, at 5:41 PM, Lorenzo Laneve <lore97drk at icloud.com <mailto:lore97drk at

Hi Lang, On Tue, 13 Aug 2019 at 20:47, Lang Hames <lhames at gmail.com> wrote: > > Sorry for the delayed reply. Looks like you have figured out how to solve your issue already. Out of interest, what did you need to do? Do you have anything that you would like to see added to http://llvm.org/docs/ORCv2.html ? > Sorry my post was misleading. I figured out below which was part of the

I’m using LLVM 3.8.0, and no, it’s the precompiled version That’s why it doesn’t give me enough info for debug > On 24 Mar 2016, at 1:53 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > This code path is not likely to crash usually. Did you build LLVM yourself? Which version are you using and can you reduce the test case to be "minimal" so that someone can

Assuming you are talking about this line: passmanager.add(tliwp); I don't see anything obviously wrong. Are you hitting an assertion or a pure crash? (if LLVM not built with assertions, please rebuild). What does your debugger gives you as a stracktrace? -- Mehdi > On Mar 23, 2016, at 3:44 PM, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sorry in