similar to: [LLVMdev] LLVM evaluation

I'm writing a peephole pass and I'm done with the X86_64 instruction level detail work. But I'm having difficulty with the basic block surgery of replacing the old MachineInst. The peephole pass gets called per MachineFunction and then iterates over each MachineBasicBlock and in turn over each MachineInst. When it finds an instruction which should be replaced, it builds a new

This is a question about optimizing the code generation in a (new) Z80 backend: The CPU has a couple of 8 bit physical registers, e.g. H, L, D and E, which are overlaid in 16 bit register pairs named HL and DE. It has also a native instruction to load a 16 bit immediate value into a 16 bit register pair (HL or DE), e.g.: LD HL,<imm16> Now when having a sequence of loading two 16

On 5/17/2018 4:04 PM, Davide Italiano via llvm-dev wrote: > On Thu, May 17, 2018 at 3:53 PM, Dávid Bolvanský via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> I was thinking about a new possible simplification in InstCombine which >> would transform code like this: >> >> const char * NAME = "Prog"; >> >> void

Hi, Can you add the following two publications from our group to the LLVM publications page. - *Alive-FP: Automated Verification of Floating Point Based Peephole Optimizations in LLVM [pdf] <http://www.cs.rutgers.edu/~santosh.nagarakatte/papers/alive-fp-sas16.pdf> *David Menendez, Santosh Nagarakatte, and Aarti Gupta *To Appear in the Proceedings of the 23rd Static Analysis

Ok, thank you, I will implement it then. As far as I see this optimization should be done in AArch64LoadStoreOptimizer, is it right? From: Eli Friedman [mailto:efriedma at quicinc.com] Sent: Thursday, November 21, 2019 11:55 PM To: Kosov Pavel <kosov.pavel at huawei.com>; LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [ARM] Peephole optimization ( instructions tst +

Hello Devs, Machine Instruction verifier pass always validates Live variable info associated with MachineInstr along with other checks. Please consider following scenario (w.r.t bugZilla 32583) 1/ MachineCSE pass may prohibit optimising out a common sub-expression for instruction using physical registers by looking at the LiveIn info of successor basic blocks. 2/ Which means we need Live

Am 07.10.2010 um 19:50 schrieb Chris Lattner: > > On Oct 6, 2010, at 6:16 PM, Gabor Greif wrote: > >> Hi all, >> >> I am slowly working on a SwitchInst optimizer (http://llvm.org/ >> PR8125) >> and now I am running into a deficiency of the x86 >> peephole optimizer (or jump-threader?). Here is what I get: >> >> >> andl $3,

Hi all, I am slowly working on a SwitchInst optimizer (http://llvm.org/PR8125) and now I am running into a deficiency of the x86 peephole optimizer (or jump-threader?). Here is what I get: andl $3, %edi je .LBB0_4 # BB#2: # %nz # in Loop: Header=BB0_1 Depth=1 cmpl $2, %edi

That flag is specifically used by the foldImmediate optimization in the Peephole pass. We don't implement the TLI foldImmediate hook the peephole pass uses on x86 so we have no reason to set the flag on any instructions What are you trying to do? ~Craig On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I had

- Please do not add any more uses of the LiveVariables pass! It is deprecated and only kept around for one last pass that isn't converted. All new code should use LiveIntervalAnalysis! - Kill flags are optional: If they are present they must be correct, but it is legal to have a value die without having a kill flag on the operand. So often a simple fix is to clear out the kill flags from

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

I am trying to categorize the machine instructions based on associated static (i.e., as encoded in .td file) machine description and the corresponding APIs. I would like to perform appropriate actions based on the kind of instruction in a tool that I am working on. For example, I'd like to distinguish between memop instructions involving immediate vs register. While it appears that I would be

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 7/26/05, Reid Spencer <reid at x10sys.com> wrote: > On Tue, 2005-07-26 at 17:25 -0700, Michael McCracken wrote: > > > Since I'm modifying llc, I have a couple small questions about that code: > > > > opt and analyze (and a couple of other places) add a verifier pass, > > but llc doesn't. > > This would seem to make sense for llc as well -

On Oct 6, 2010, at 6:16 PM, Gabor Greif wrote: > Hi all, > > I am slowly working on a SwitchInst optimizer (http://llvm.org/PR8125) > and now I am running into a deficiency of the x86 > peephole optimizer (or jump-threader?). Here is what I get: > > > andl $3, %edi > je .LBB0_4 > # BB#2: # %nz >

Sure. Attached is the file but here are the functions. The first uses a fixed bit offset. The second has a indexed bit offset. Compiling with llc -O3, LLVM version 3.7.0svn, it compiles the IR from IsBitSetB() using btq %rsi, %rdi. Good. But then it compiles IsBitSetA() with shrq/andq, which is is pretty much what Clang had generated as IR. shrq $25, %rdi andq $1, %rdi LLVM should be able to

I'm tracking down an X86 code generation malfeasance regarding BT (bit test) and I have some questions. This IR *matches* and then *X86TargetLowering::LowerToBT **is called:* %and = and i64 %shl, %val * ; (val & (1 << index)) != 0 ; *bit test with a *register* index This IR *does not match* and so *X86TargetLowering::LowerToBT **is not called:* %and = lshr i64 %val, 25

Hi Quentin, Yes, the code allows to process connected instructions. Although it should be taken into account that the instruction next to the current processed instruction must never be erased because this invalidates iterator. I've been fixing a bug in AArch64InstrInfo::optimizeCompareInstr: instructions are converted into S form but it's not checked that they produce the same flags as

Hello, I want to present my project for GSoC 2011 for LLVM below. It would be very nice to hear suggestions and your opinion, thanks! Superoptimization for LLVM IR Objective This project focuses on implementing superoptimization algorithms targeted at the LLVM IR. The project uses arbitrary LLVM bitcode as a training set to discover new peephole optimizations that can be later integrated into

On Thu, May 17, 2018 at 3:53 PM, Dávid Bolvanský via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello, > > I was thinking about a new possible simplification in InstCombine which > would transform code like this: > > const char * NAME = "Prog"; > > void printer(char **arr, int len) { > for (int i = 0; i < len; ++i) { > printf("%s: