search for: cgp

Hi, I want to improve the way CGP sinks the incoming values of a PHI node towards memory accesses. Improving it means a lot to some of our key benchmarks, and I believe can benefit many general cases as well. CGP's OptimizeMemoryInst function handles PHI nodes by running AddressingModeMatcher on all incoming values to see whet...

...n DAGCombiner to do >> such shrinking. >> >> However, DAGCombiner has the one-basic-block-a-time limitation, so we >> started to implement a new shrinking optimization in >> https://reviews.llvm.org/D30416, and initially put it in instcombine, >> then moved it to CGP because we want to use some TargetLowering >> information. >> >> The initial implementation in D30416 only supports load-and-or-store >> pattern matching, and it uses a inst-by-inst scan as a safety check to >> make sure there is no other memory write insn between the...

...1] store i32 %tmp57, i32* %NUM %tmp58 = load i32* %NUM ; <i32> [#uses=1] %tmp59 = icmp ne i32 %tmp58, -1 ; <i1> [#uses=1] %tmp5960 = zext i1 %tmp59 to i8 ; <i8> [#uses=1] %toBool61 = icmp ne i8 %tmp5960, 0 ; <i1> [#uses=1] br i1 %toBool61, label %bb, label %bb62 CGP: Found local addrmode: [Base:%argc_addr] CGP: Found local addrmode: [Base:%argv_addr] CGP: Found local addrmode: [Base:%argc_addr] CGP: Found local addrmode: [Base:%argv_addr] CGP: Found local addrmode: [4 + Base:%tmp4] CGP: Found local addrmode: [Base:%iftmp.0] CGP: F...

...ouldMergeGEPs in InstructionCombining > > > Hi Daniel, > > Thanks! I wonder if there's a way to reuse some code in > Reassociation. Looks like most of the logic we want to implement is > in Reassociate.cpp already. But the entire pass seems too expensive > to run with CGP or after each instcombine. > I don't think that the algorithm itself is too expensive for CGP (and we already do dominance-aware GEP splitting in CGP), we don't do any of this at -O0 anyway, but we need something that specifically handles GEPs. For most operations (adds, etc.) reassoci...

...> - %c = false and %b is poison >> >> This disallows 3) and some transformations of 1). Since 3) is only >> performed in CodeGenPrepare, we can safely ignore it (no aggressive >> optimizations are run afterwards). > > This strikes me as a dangerous game to play. CGP's transformations need to be semantically sound (even if they are anti-canonical). In part, this is because our IR-level analyses are used by CGP. Moreover, targets after CGP run IR-level transformations, and having different semantic rules there is going to make code reuse hard in subtle ways....

Apologies if this is in the archive - did look but couldn't find it. Does anyone have any experience of migrating from CommunigatePro to Dovecot? We currently run CGP 5.3.4, supporting a small system (20 or so users, one domain). We've been using it for years, and have a mixed bag of MailDir and mbox folders accessed via IMAP clients. Some users have large mail accounts (15GB total). We're looking to move as CGP is evolving into a complex "Messag...

...al type bitfield shrinking. Currently, llvm depends on DAGCombiner to do such shrinking. However, DAGCombiner has the one-basic-block-a-time limitation, so we started to implement a new shrinking optimization in https://reviews.llvm.org/D30416, and initially put it in instcombine, then moved it to CGP because we want to use some TargetLowering information. The initial implementation in D30416 only supports load-and-or-store pattern matching, and it uses a inst-by-inst scan as a safety check to make sure there is no other memory write insn between the load and store (no alias query is done). Af...

...t; Where? On the mailing list? > If I remember correctly the plan was that the second half of the pipe > should start with GVN (which currently runs after the loop passes). After > that come the loop passes, the Vectorizers (loop vectorization first), and > finally LSR, Lower-switch, CGP, etc. I think that when we discussed this > most people argued that the inliner should be before GVN and the loop > passes. It would be interesting to see the performance numbers for the new > pass order. > This doesn't make a lot of sense to me yet. The inliner, GVN, and the loo...

...up with a general draft for the ideal pass ordering. If I remember correctly the plan was that the second half of the pipe should start with GVN (which currently runs after the loop passes). After that come the loop passes, the Vectorizers (loop vectorization first), and finally LSR, Lower-switch, CGP, etc. I think that when we discussed this most people argued that the inliner should be before GVN and the loop passes. It would be interesting to see the performance numbers for the new pass order. Nadav -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:/...

...= load i32* %i, align 4 %inc = add nsw i32 %2, 1 store i32 %inc, i32* %i, align 4 br label %for.cond AFTER: for.inc: ; preds = %for.cond %2 = load i32* %i, align 4 %inc = add nsw i32 %2, 1 store i32 %inc, i32* %i, align 4 br label %for.cond CGP: Found local addrmode: [Base:%n.addr] CGP: Found local addrmode: [Base:%i] CGP: Found local addrmode: [Base:%i] CGP: Found local addrmode: [Base:%n.addr] CGP: Found local addrmode: [Base:%i] CGP: Found local addrmode: [Base:%i] Computing probabilities for for.inc set e...

Dear Community, I'm trying to implement optimization described in PR26223 and meet the following bail out condition in CodeGenPrepare::optimizeMemoryInst. // Break use-def graph loops. if (!Visited.insert(V).second) { Consensus = nullptr; break; } So while traversing thorough phi nodes from memory instruction to find addr mode we bail out if we meet some instruction

...in the past :) Do you think we still need some way to disable just the library call simplification now that it is a part of the instruction combiner? >> 1. What should be done about the `SimplifyFortifiedLibCalls` use in >> `CodeGenPrepare`? > > I think it stays where it is. CGP runs right before the code generator > kicks in. The idea here is that we want to leave the fortified libcalls > in the IR as long as possible on the off chance that instcombine or something > else can expose range information about underlying buffers... however, if we > get all the wa...

Hi all, I'm working on a new pass to optimize comparison chains. Motivation Clang currently generates inefficient code when dealing with contiguous member-by-member structural equality. Consider: struct A { bool operator==(const A& o) const { return i == o.i && j == o.j; } uint32 i; uint32 j; }; This generates: mov eax, dword ptr [rdi] cmp eax,

> we lower llvm.objectsize later than we should Is there a well-accepted best (or even just better) place to lower objectsize? I ask because I sorta fear that these kinds of problems will become more pronounced as llvm.is.constant, which is also lowered in CGP, gains popularity. (To be clear, I think it totally makes sense to lower is.constant and objectsize in the same place. I'm just saying that if the ideal piece of code to do that isn't CGP, ...) On Fri, Jun 29, 2018 at 12:21 PM Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org>...

...should, however, pull these apart somewhere, and probably in some way >> that is address-mode aware. I'd recommend trying to split non-free (via the >> addressing-mode) loop-invariant parts of GEPs out of loops in CodeGenPrep. >> > > Thanks, Hal. I'll have a look at CGP to see how this might be done. It's > a little more complicated than just pulling the GEP apart, there needs to > be a loop-invariant-aware reassociation to undo the damage done by the > initial merge. > So, this is in fact, just using the ranks reassociation would normally use, t...

...t; This disallows 3) and some transformations of 1). Since 3) is only >> >> performed in CodeGenPrepare, we can safely ignore it (no >> >> aggressive >> >> optimizations are run afterwards). >> > >> > This strikes me as a dangerous game to play. CGP's transformations >> > need to be semantically sound (even if they are anti-canonical). >> > In part, this is because our IR-level analyses are used by CGP. >> > Moreover, targets after CGP run IR-level transformations, and >> > having different semantic rule...

...ng loops, simplifying them, etc. all directly feed the iterative simplification needed by GVN and the inliner. > > We need a *second* loop pass that happens after the iterative CGSCC walk which does the further optimizations such as (potentially indvars, ) the vectorizers, LSR, lower-switch, CGP, CG. I think we actually want most of the post CGSCC module passes to run after the vectorizers and before LSR to fold away constants and globals that look different after vectorization compared to before, but aren't significantly shifted by LSR and CGP. In terms of mental model, is it best to...

Hi, I am working on a patch for CodeGenPrepare, which introduces a use of TargetLoweringBase::InstructionOpcodeToISD (see [1] for the details). This is usual for CodeGenPrepare to use the TargetLowering class when it is available, however, using this particular function creates linking problems. ** Context ** The TargetLowering class is part of libLLVMCodeGen, which means that in theory every

...dyn_cast<IntInit>(N->getLeafValue())) { // If this is the root of the dag we're matching, we emit a redundant opcode // check to ensure that this gets folded into the normal top-level // OpcodeSwitch. if (N == Pattern.getSrcPattern()) { const SDNodeInfo &NI = CGP.getSDNodeInfo(CGP.getSDNodeNamed("imm")); AddMatcher(new CheckOpcodeMatcher(NI)); } return AddMatcher(new CheckIntegerMatcher(II->getValue())); } ------------------------------------------------------------------------------------------------- This code seems to retrie...

...You can also land the new LibCallSimplifier infrastructure first before you switch anything over to use it, if that helps. > Open Questions > ============== > > 1. What should be done about the `SimplifyFortifiedLibCalls` use in > `CodeGenPrepare`? I think it stays where it is. CGP runs right before the code generator kicks in. The idea here is that we want to leave the fortified libcalls in the IR as long as possible on the off chance that instcombine or something else can expose range information about underlying buffers... however, if we get all the way to code gen, then...