similar to: [LLVMdev] SimplifyCFG vs loops

On Wed, Oct 17, 2012 at 8:41 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > Hello All, > > The current implementation of the CFG simplification is loop-agnostic. In > the past I have observed that it can perform transformations that can be > detrimental to the loop structure. One example that I recall, is > converting a loop like this: > while (...)

On 10/17/2012 11:09 AM, Dan Gohman wrote: > On Wed, Oct 17, 2012 at 8:41 AM, Krzysztof Parzyszek > <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote: > > Hello All, > > The current implementation of the CFG simplification is > loop-agnostic. In the past I have observed that it can perform > transformations that can be

On Oct 17, 2012, at 9:38 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> The current implementation of the CFG simplification is >> loop-agnostic. In the past I have observed that it can perform >> transformations that can be detrimental to the loop structure. One >> example that I recall, is converting a loop like this: >>

I actually submitted a patch to fix this very problem quite a while back, but I don't think it was ever added to the baseline: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110711/124136.html I have also explained why it is important to avoid the creation of new loops in an optimizer that performs analysis on the looping structure. I now need to keep this patch updated

On 17 October 2012 16:41, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > Hello All, > > The current implementation of the CFG simplification is loop-agnostic. In > the past I have observed that it can perform transformations that can be > detrimental to the loop structure. One example that I recall, is converting > a loop like this: > while (...) { >

On Thu, Oct 18, 2012 at 10:12 AM, Andrew Clinton <andrew at sidefx.com> wrote: > I actually submitted a patch to fix this very problem quite a while back, > but I don't think it was ever added to the baseline: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110711/124136.html > > I have also explained why it is important to avoid the creation of new

On 10/17/2012 2:11 PM, James Courtier-Dutton wrote: > > I thing to keep in mind is this is CFG, and can be unstructured, or > after various transformations, not representable in higher level > language structures such as while loops. Having a specific loop structure with specific requirements, such as single back edge can make loop optimizations (and loop nest optimizations in

On 10/18/2012 01:26 PM, David Blaikie wrote: > On Thu, Oct 18, 2012 at 10:12 AM, Andrew Clinton<andrew at sidefx.com> wrote: >> I actually submitted a patch to fix this very problem quite a while back, >> but I don't think it was ever added to the baseline: >> >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110711/124136.html >> >>

What was the resolution to this issue? Was the patch accepted? I am also running into an issue with this. Basically, I have a fairly simple loop with control flow, and the loopSimplify pass is turning it into a nested loop in order to remove multiple backedges. This is making the loop more complicated, not simple, and is causing our backend to miss performance opportunities. In particular, I

On 11/27/2012 8:03 AM, Hal Finkel wrote: > > This still leaves the question of exactly how to attach metadata to loops, etc. In one implementation, the loops had a fixed structure: guard branch, preheader, header and loop body, optional epilog. The structure was clearly identified by various means (flags, bits, etc.). No optimization in the optimizer (roughly a counterpart of the

----- Original Message ----- > From: "Bjorn De Sutter" <bjorn.desutter at elis.ugent.be> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 27, 2012 6:49:39 AM > Subject: Re: [LLVMdev] loop pragmas > > I am thinking about another use of annotations that fits in a longer > term vision, which centers around feeding compilers with information > from

On Mar 26, 2014, at 6:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 3/26/2014 11:39 AM, İsmail Dönmez wrote: >> >> make check-all but yes make check would suffice. Thanks! > > I see two reported failures: > > > FAIL: LLVM :: BugPoint/compile-custom.ll (459 of 9992) > ******************** TEST 'LLVM ::

Hi all, I am noticing a significant degradation in execution performance in loops with just one backedge than loops with two backedges. Unifying the backedges into one will also cause the slowdown. To replicate this problem, I used the C code in https://gist.github.com/sklam/11f11a410258ca191e6f263262a4ea65 and checked against clang-3.8 and clang-4.0 nightly. Depending on where I put the

On 10/17/2012 11:55 AM, Chris Lattner wrote: > On Oct 17, 2012, at 9:38 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> There is no reason for two back edges. This loop could look like this: >> >> header: >> ... >> ... >> if (cond) goto tail; else goto next; >> next: >> ... >> tail: >> if

In https://bugs.llvm.org/show_bug.cgi?id=38011 (see also https://reviews.llvm.org/D48721) a problem was revealed related to llvm.loop metadata. The fault was that clang added the !llvm.loop metadata to branches outside of the loop (not only the loop latch). That was not handled properly by some opt passes (simplifying cfg) since it ended up merging branch instructions with different !llvm.loop

Hi all, In order to identify loops I'm using the DILexicalScope metadata attached to the loop latch, but with some combinations of optimisations that metadata seems to disappear. For example, when -simplifycfg removes a block because it only contains a branch, and -loop-simplify recreates that block because it turned out to be a back-edge of some loop, the metadata gets removed.

Hello, I’m getting some failures on our internal testing happening after this commit. I dug a little bit into it and it ended up begin caused by the fact that this optimization is sinking some instructions that shouldn’t be sunk In particular we have some loads that need to have a constant address to be selected, because they load from a “special address space”. What the optimization is doing

All, I have some code that looks like the following: { double a, b, c; for (...) { ... a = lots of FP math; b = lots of FP math; c = lots of FP math; if (cond) { a = 0.0; b = 0.1; c = 0.2; } ... } } Could we not convert the hammock into a diamond and move the initial computation of a, b, and c into the else block. Something like this: {

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Chandler Carruth" <chandlerc at google.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, July 16, 2015 1:58:02 AM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration variable > ----- Original Message ----- > >

Hi Chad, On Aug 6, 2013, at 7:46 AM, Chad Rosier <chad.rosier at gmail.com> wrote: > All, > I have some code that looks like the following: > > { > double a, b, c; > for (...) { > ... > a = lots of FP math; > b = lots of FP math; > c = lots of FP math; > if (cond) { > a = 0.0; > b = 0.1; > c = 0.2; >