search for: subsumption

...erform value numbering on virtual/physical registers, which does not map very well to status register bits that are implicitly defined. Any chance to recast this issue as a target-independent (but cmp-specific) peephole problem, that just looks into predecessor blocks and applies (target-hook-like) subsumption checks for 'cmp' instructions? I am thankful for any hint, cheers, Gabor > > -Chris

...virtual/physical registers, which > does not map very well to status register bits that are implicitly > defined. > Any chance to recast this issue as a target-independent > (but cmp-specific) peephole problem, that just looks into > predecessor blocks and applies (target-hook-like) subsumption > checks for 'cmp' instructions? I think that extending MachineCSE to do a simple dominator tree walk with llvm::ScopedHashTable would make sense. Status register bits should be handled just like any other physreg. On x86, this is a def of EFLAGS physreg for example. On PPC, the cond...

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

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 >

Hi the appended IR code does not optimize to my liking :) this is the interesting part in x86_64, that got produced via clang -Os: --- movq -16(%r12), %rax movl -4(%rax), %ecx andl $2298949, %ecx ## imm = 0x231445 cmpq $2298949, (%rax,%rcx) ## imm = 0x231445 leaq 8(%rax,%rcx), %rax cmovneq %r15, %rax movl $2298949, %esi ## imm = 0x231445 movq %r12, %rdi movq %r14,

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

...5 struct_vector.ll 19 328103 0 0.03 328074 0 0.03 328074 student2.ll 32 70920 2 0.01 70847 0 0.01 70866 student3.ll 35 147276 1 0.02 147172 0 0.02 147183 suboptalign11.ll 4 103224 0 0.02 103209 0 0.01 103209 subspic.ll 6 36624 0 0.01 36589 0 0.01 36589 subst.ll 79 104379 6 0.02 103147 0 0.02 102930 subsumption.ll 129 312529 7 0.03 310822 0 0.03 306700 suicide.ll 1 7123 0 0.01 7097 0 0.01 7097 sumarray2d.ll 2 7997 0 0.01 7985 0 0.01 7985 sumarray-dbl.ll 2 7099 0 0.01 7083 0 0.01 7083 sumarray.ll 2 5552 0 0.01 5536 0 0.01 5536 sumarraymalloc.ll 5 8625 0 0.01 8613 0 0.01 8613 sumcol.ll 15 21294 0 0.01 21269...