similar to: [LLVMdev] Turning Off Backend Passes

On Sep 1, 2009, at 12:07 PM, David Greene wrote: > So LLVMTargetMachine.cpp adds lots of transformation passes in the > various addPasses* routines. We'd prefer not to run all of these > things (LSR, for example). We've sort of dealt with it for now but > we'd really like to be able to turn some of these things off in a > convenient way. > > We could just

On Tuesday 01 September 2009 14:27, Evan Cheng wrote: > If you have a custom compiler, why not have llvm-gcc (or whatever > frontend you use) create its own pass manager? That way, it can > control the exactly what passes it wants. Because addPasses* do a lot of useful stuff. There's already a "Fast" flag but it's overloaded. What if we replaced it with a bitvector

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, January 06, 2017 11:10 AM > To: Sumanth Gundapaneni > Cc: LLVM Developers > Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed > from clang. > > > > On Jan 6, 2017, at 10:56 AM, Sumanth

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

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:

The functions that I placed in ScalarTargetTransformInfo are functions what were used by LSR and LowerInvoke. getJumpSize and getJumpAlignment are used by LowerInvoke. Do you suggest that I remove them from TargetLowering and keep them in ScalarTargetTransformInfo ? Thanks, Nadav On Oct 9, 2012, at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi Nadav, > > The

Hi Steve, Do you primarily find this to help for nested loops? If so, that could be because LSR explicitly bails out of processing them: // Skip nested loops until we can model them better with formulae. if (!L->empty()) { DEBUG(dbgs() << "LSR skipping outer loop " << *L << "n"); return; } I don't know how much time you're

I checked recent revisions 138624 and 138620 and both produce this log with gcc-4.6.0 on FreeBSD-8.2-STABLE amd64: gmake[2]: Entering directory `/usr/home/yuri/llvm-svn/llvm-objects/lib/CodeGen' llvm[2]: Compiling LLVMTargetMachine.cpp for Release build /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:253:3: error: ‘AsmStreamer’ does not name a type

On Wed, Sep 2, 2015 at 5:36 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > Coremark really isn't a good enough test - have you run the LLVM test suite > with this patch, and what were the performance differences? For the test suite single source benches, the 235 tests improved performance, 2 regressed and 705 were unchanged. That seems very optimistic.

On Sun, Feb 22, 2009 at 3:25 PM, Wesley J. Landaker <wjl at icecavern.net> wrote: > * Has anyone else out there targeted (or tried to target) a stack machine > before? Was it successfull? What problems did you have? Haven't done that, and I don't think there are any existing backends like this. It should be feasible, though; the backend code is pretty flexible. > * What

Hi, I would like some help regarding the LSR pass. It seems that it likes to duplicate address calculations as in the case above, which is highly undesirable on my target. I wonder if there is any way to tell LSR to not duplicate the code in cases like this? Or could I perhaps run CSE after LSR again? What is the logic behind this transformation? It seems that a LSR pass should not insert a

The thread here should help. http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-May/031624.html On May 28, 2010, at 6:35 AMPDT, Curtis Faith wrote: > I have some LLVM IR after the optimization passes defined in createStandardModulePasses with the optimization level set to 3. It contains what appears to me to be an easily optimizable branch statement. > > In particular, note in the code

I have some LLVM IR after the optimization passes defined in createStandardModulePasses with the optimization level set to 3. It contains what appears to me to be an easily optimizable branch statement. In particular, note in the code below that at the end of the "loop" BasicBlock that there is a conditional branch where in the false case, it branches to the label

Which cases does this pass handle which aren't otherwise optimized out by passes like GlobalValueNumbering or DeadCodeElimination? Thanks, Jake VanAdrighem On Thu, Sep 10, 2015 at 2:35 PM, Steve King <steve at metrokings.com> wrote: > Hello LLVM, > It seems this thread has gone cold. Is there some low risk way for > the community to take the new pass for a test drive? >

The IR after LSR is: *** IR Dump After Loop Strength Reduction *** ; Preheader: entry: tail call void @fill_array(i32* getelementptr inbounds ([10 x i32], [10 x i32]* @buffer, i32 0, i32 0)) #2 br label %while.body ; Loop: while.body: ; preds = %while.body, %entry %lsr.iv = phi i32 [ %lsr.iv.next, %while.body ], [ 0, %entry ] %uglygep = getelementptr

Hi. In my backend I get false code after using StrengthLoopReduction. In the generated code the loop index variable is multiplied by 8 (correct, everything is 64 bit aligned) to get an address offset, and the index variable is incremented by 1*8, which is not correct. It should be incremented by 1 only. The factor 8 appears again. I compared the debug output

Hm, no. I expect byte addresses - everywhere. The compiler should not know that the arch needs word addresses. During lowering LOAD and STORE get explicit conversion operations for the memory address. Even if my arch was byte addressed the code would be false/illegal. Boris > Am 09.06.2020 um 19:36 schrieb Eli Friedman <efriedma at quicinc.com>: > > Blindly guessing here,

Hi, The target supports indexing by register or immediate. Multiplications are not supported by any load / store instructions. Would it be possible to make LSR aware of this? Thanks, Jonas Paulsson -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Saturday, December 01, 2012 5:59 AM To: Jonas Paulsson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LSR pass

I've noticed that there was an attempt to mitigate ExitValues problem in https://reviews.llvm.org/D12494 that went nowhere. Were there particular issues with that approach? -- Danila From: Philip Reames [mailto:listmail at philipreames.com] Sent: Saturday, August 10, 2019 02:05 To: Danila Malyutin <Danila.Malyutin at synopsys.com>; Finkel, Hal J. <hfinkel at anl.gov> Cc: llvm-dev

----- Original Message ----- > From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> > To: llvmdev at cs.uiuc.edu > Sent: Monday, November 26, 2012 1:40:24 PM > Subject: [LLVMdev] LSR pass > > > > > > Hi, > > > > I would like some help regarding the LSR pass. It seems that it likes > to duplicate address calculations as in the