search for: simplifyinstruction

I notice that GetUnderlyingObject has a few checks, but alloca isn't one of them. Then it fall backs to SimplifyInstruction which doesn't know about alloca so falls back to just trying to constant fold it. This seems a little silly since I assume alloca can't be constant folded. Should we just detect this early in GetUnderlyingObject and stop? ~Craig -------------- next part -------------- An HTML attachment wa...

...gt; Ping > > ~Craig > > On Fri, Apr 7, 2017 at 1:25 PM, Craig Topper <craig.topper at gmail.com > <mailto:craig.topper at gmail.com>> wrote: > > I notice that GetUnderlyingObject has a few checks, but alloca > isn't one of them. Then it fall backs to SimplifyInstruction which > doesn't know about alloca so falls back to just trying to constant > fold it. This seems a little silly since I assume alloca can't be > constant folded. Should we just detect this early in > GetUnderlyingObject and stop? > > ~Craig > > -...

> > Instead of adding the operands to a list, erase the instruction and add them to the worklist wouldn’t be probably faster something like: > > if (Instruction *Used = dyn_cast<Instruction>(*OI)) > if (Used->hasOneUse()) > WorkList.insert(Used); > > If it has one use is going to be the instruction we are going to remove anyway, right? I don’t think this

LLVM has two similar bits of infrastructure: a simplifyInstructionsInBlock function and a SimplifyInstructions pass, both intended to be lightweight “fix up this code without doing serious optimizations” functions, as far as I can tell. I don’t think either is used in a performance-sensitive place in-tree; the former is mostly called in minor places when doing CFG...

...e has a DomTree and AssumptionCache that are required, but it doesn't pass them to SimplifyBinOp in a bunch of cases. JumpThreading has TLI but doesn't pass it to SimplifyCmpInst. CVP at least admits it has a problem: "CorrelatedValuePropagation.cpp: // FIXME: Provide TLI, DT, AT to SimplifyInstruction. CorrelatedValuePropagation.cpp: if (Value *V = SimplifyInstruction(P, DL)) { " (This is because it uses LVI, which requires those things, but it doesn't ask for them itself) Assuming this is not deliberate, it would seem to me to just be easiest to set up the query structure once in the...

...et-stream Size: 4404 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/2e3c515f/attachment-0005.obj> -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch Type: application/octet-stream Size: 1498 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/2e3c515f/attachment-0006.obj> -------------- next part -------------- On Nov 15, 2012, at 10:51 AM, Evan Cheng <evan.cheng at apple....

...;0004-Fast-math-flags-for-LLVM-IR-parsing-and-printing.patch> > <0005-Fast-math-flags-for-the-bitcode.patch> > <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> > <0007-Fast-math-optimization-fold-multiply-by-zero.patch> > <0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> > > On Nov 15, 2012, at 10:51 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> >> On Nov 15, 2012, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote: >> >>> >>> On Nov 15, 2012, at 10:38 AM, Evan Chen...

...flags-for-LLVM-IR-parsing-and-printing.patch> >> <0005-Fast-math-flags-for-the-bitcode.patch> >> <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> >> <0007-Fast-math-optimization-fold-multiply-by-zero.patch> >> <0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> >> >> On Nov 15, 2012, at 10:51 AM, Evan Cheng <evan.cheng at apple.com> wrote: >> >>> >>> On Nov 15, 2012, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote: >>> >>>> >>>> On Nov...

...flags-for-LLVM-IR-parsing-and-printing.patch> >> <0005-Fast-math-flags-for-the-bitcode.patch> >> <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> >> <0007-Fast-math-optimization-fold-multiply-by-zero.patch> >> <0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >

...inting.patch> >>>> <0005-Fast-math-flags-for-the-bitcode.patch> >>>> <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> >>>> <0007-Fast-math-optimization-fold-multiply-by-zero.patch> >>>> <0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> >>>> >>>> On Nov 15, 2012, at 10:51 AM, Evan Cheng <evan.cheng at apple.com> wrote: >>>> >>>>> >>>>> On Nov 15, 2012, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote: >>>>...

...R-parsing-and-printing.patch> >>> <0005-Fast-math-flags-for-the-bitcode.patch> >>> <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> >>> <0007-Fast-math-optimization-fold-multiply-by-zero.patch> >>> <0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> >>> >>> On Nov 15, 2012, at 10:51 AM, Evan Cheng <evan.cheng at apple.com> wrote: >>> >>>> >>>> On Nov 15, 2012, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote: >>>> >>>>&g...

...et-stream Size: 4406 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/4780f05d/attachment-0005.obj> -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch Type: application/octet-stream Size: 1488 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/4780f05d/attachment-0006.obj> -------------- next part --------------

...R-parsing-and-printing.patch> >>> <0005-Fast-math-flags-for-the-bitcode.patch> >>> <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> >>> <0007-Fast-math-optimization-fold-multiply-by-zero.patch> >>> <0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >

...to do a better job of > simplifying by reducing the number of phis, etc... > > I don't see a significant problem in adding this to > FoldTwoEntryPhiNodes. The relevant changes would be isolated to the > initial loop over the phis, and would be somewhat parallel to the use > of simplifyInstruction. > > The main question is to how to make this conditional on a per-target > basis, i.e. how to properly define any relevant heuristics via > TargetTransformInfo. > > Cheers, > Nicolai > > > > -- > Lerne, wie die Welt wirklich ist, > aber vergiss niemals, wie s...

...;0004-Fast-math-flags-for-LLVM-IR-parsing-and-printing.patch> > <0005-Fast-math-flags-for-the-bitcode.patch> > <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> > <0007-Fast-math-optimization-fold-multiply-by-zero.patch> > <0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...;0003-Fast-math-flags-for-LLVM-IR-parsing-and-printing.patch> > <0004-Fast-math-flags-for-the-bitcode.patch> > <0005-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> > <0006-Fast-math-optimization-fold-multiply-by-zero.patch> > <0007-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> > <0008-Fast-math-flags-documentation-added-to-LangRef.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/8b600af5/attachment.html>

SimplifyCFG FoldTwoEntryPhiNode looks to simplify all 2 entry phi nodes in a block, if it can't do them all then it won't do any and returns. There is a lot of code that is directly in this function geared toward this requirement. Is it possible currently to get this function (or pass) to simply fold "some" of the phis (without having to fold them all?). I understand that

...k I can at least work around the > issue in my frontend. > > Ignoring GVN for a second though, and just looking at Early CSE, it seems > to me that at least in this pass that there is the potential for an easy > fix. Here the issue appears to be that we hit > > if (Value *V = SimplifyInstruction(Inst, DL, &TLI, &DT, &AC)) > > immediately replacing %1 with 3 before we even reach %3. If we were to > record this replacement in EarlyCSE::AvailableValues, wouldn't that address > the issue? I'll try this out and see. > > v/r, > Josh > > On Fri, Jun...

Yeah, that change is completely unrelated, that is about correctness, this is about optimization. I'm working on a proposal to just fix assume at some point to deal with the former issue. The problem with this testcase is that all the ways assume is propagate expect the variable in the assume to later be used. <This is the main way assume constants are propagated> bool

Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. --------------------- static bool mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) { if (succ == pred) return false; if (pred->getFirstNonPHI() != pred->getTerminator()) return false; //