search for: peepholeoptimizer

Hi all, The register allocator that I implemented is failing in the LLVM cvs version, but not in LLVM 1.1. The generated code fails a check in the x86 peephole optimizer: llc: PeepholeOptimizer.cpp:128: bool <unnamed>::PH::PeepholeOptimize(llvm::Machi neBasicBlock&, llvm::ilist_iterator<llvm::MachineInstr>&): Assertion `MI->getNum Operands() == 2 && "These should all have 2 operands!"' failed. I've tracked it down to a difference betwee...

...*pseudo instruction expansion*. How could *LowerToBT'*s caller have enough context to match the immediate IR version? In fact, lli isn't calling *LowerToBT* so it isn't matching. But isn't this really a *peephole optimization* issue? LLVM has a generic peephole optimizer, *CodeGen/PeepholeOptimizer.cpp *which has exactly one subclass in *NVPTXTargetMachine.cpp.* But isn't it better to deal with X86 *LowerToBT* in a *PeepholeOptimizer* subclass where you have a small window of instructions rather than during pseudo instruction expansion where you have really one instruction? *PeepholeOpti...

Hi, I find it's quite strange how condition dependent instructions are processed in PeepholeOptimizer::runOnMachineFunction: 01577 if ((isUncoalescableCopy(*MI) && 01578 optimizeUncoalescableCopy(MI, LocalMIs)) || 01579 (MI->isCompare() && optimizeCmpInstr(MI, &MBB)) || 01580 (MI->isSelect() && optimizeSelect(MI, LocalMIs))) {...

...s for combinations CMP+BRC and CMP+SEL. In the context of optimizeCmpInstr I have all information about CmpInstr. I simply go down and check all instructions which use AArch64::NZCV whether they can be substituted with the simpler version. After all I delete CmpInstr. This approach contradicts with PeepholeOptimizer design because BRC and SEL must be processed in corresponding functions. Yes, 'analyzeCompare' is cheap but in optimizeCondBranch and in optimizeSelect we need to go up to find the instruction defining condition flags. In case of BRC CMP should not be far from it but I am not sure about SEL...

...ansion*. How could > *LowerToBT'*s caller have enough context to match the immediate IR > version? In fact, lli isn't calling *LowerToBT* so it isn't matching. But > isn't this really a *peephole optimization* issue? > > LLVM has a generic peephole optimizer, *CodeGen/PeepholeOptimizer.cpp *which has > exactly one subclass in *NVPTXTargetMachine.cpp.* > > But isn't it better to deal with X86 *LowerToBT* in a *PeepholeOptimizer* subclass > where you have a small window of instructions rather than during pseudo > instruction expansion where you have really one in...

...sion. How could LowerToBT's caller have enough context to match the immediate IR version? In fact, lli isn't calling LowerToBT so it isn't matching. But isn't this really a peephole optimization issue? >>>> >>>> LLVM has a generic peephole optimizer, CodeGen/PeepholeOptimizer.cpp which has exactly one subclass in NVPTXTargetMachine.cpp. >>>> >>>> But isn't it better to deal with X86 LowerToBT in a PeepholeOptimizer subclass where you have a small window of instructions rather than during pseudo instruction expansion where you have really one...

...istence and contents of an MMO for optimization legality checks.  As a simple example, we won't fold a load unless we can examine it's MMO to ensure the access is not volatile.  At the moment, this would seem to mean that GlobalISEL generated code can't have load folding done by the PeepholeOptimizer.  Unless I'm missing something?  I'm very new to GlobalISEL. Philip

On Feb 17, 2011, at 10:35 PM, Вадим Марковцев wrote: > Hello everyone, > > I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". > Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Adding separate "s" instructions is

Hello everyone, I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Besides, I propose the codegen optimization based on them, which removes the redundant comparison in patterns like orr

Hi, GlobalISel is fantastic, but obviously lacks a lot of the transforms that makes SelectionDAG so good. Whilst it's plenty usable, you'll find yourself wanting/needing to add a lot of manual little transforms to clean things up. I know of the RFC for a new Combiner with its own syntax (https://reviews.llvm.org/D54286 is the latest I can find of it), but after manually adding my Nth

On Aug 18, 2010, at 9:56 AM, Chris Lattner wrote: > On Aug 18, 2010, at 9:22 AM, Bob Wilson wrote: >> I'm looking at llvm-generated ARM code that has some unnecessary UXTB (zero extend) instructions, and it seems to me that doing type legalization as an entirely local transformation is not the best approach. > > That's true, but doing isel as a purely local approach

Alp noted that the current setup on how phab reviews land on the list are not working for him. I'd be curious whether his setup is special, or whether there are more widespread problems. If this is more widely perceived as a problem, please speak up, and I'll make sure to prioritize the fixes (note that this is unrelated to the "lost email" problem - those are always highest

...cpp for Release+Asserts build llvm[2]: Compiling OptimizePHIs.cpp for Release+Asserts build llvm[2]: Compiling PHIElimination.cpp for Release+Asserts build llvm[2]: Compiling PHIEliminationUtils.cpp for Release+Asserts build llvm[2]: Compiling Passes.cpp for Release+Asserts build llvm[2]: Compiling PeepholeOptimizer.cpp for Release+Asserts build llvm[2]: Compiling PostRASchedulerList.cpp for Release+Asserts build llvm[2]: Compiling ProcessImplicitDefs.cpp for Release+Asserts build llvm[2]: Compiling PrologEpilogInserter.cpp for Release+Asserts build llvm[2]: Compiling PseudoSourceValue.cpp for Release+Asserts...