similar to: Structurizing multi-exit regions

On Mar 16, 2006, at 8:47 PM, Chris Lattner wrote: > On Thu, 16 Mar 2006, Eric Kidd wrote: >> The duplicate loads appear at the top of the %regex6 and %regex2 >> blocks below. I've tried various alias analysis implementations >> either alone or in combination. > > LICM doesn't remove common subexpressions, also -load-vn doesn't > affect LICM. Try

On Mar 17, 2006, at 7:54 AM, Eric Kidd wrote: > Unfortunately, this generates really weird code on the LLVM 1.6 > PowerPC backend: > > LBB_matches_1: ; regex6 > lbz r4, 0(r3) > LBB_matches_2: ; NodeBlock > rlwinm r5, r4, 0, 24, 31 > cmplwi cr0, r5, 98 > blt cr0, LBB_matches_4 ; LeafBlock > LBB_matches_3: ; LeafBlock1 >

Hi! I'm trying to run Blender using Mesa OpenCL implementation on a radeonsi card. First the kernel didn't want to compile, but that was caused by a bug in it (they were using . instead of -> in 1 place), and after fixing this bug I've got the kernel to compile... ...But after that, LLVM started to crash during translation of IR into shader code with R600 backend.

Hi, I've been investigating the StructurizeCFG pass, and it looks like it has trouble handling CFG edges that break out of a loop and go directly to the function exit. Am I running up against a bug in the structurizer, or a general limitation of the algorithm used? As an aside, is there any documentation for the algorithm used? Is it based on a published paper? The input IR I have is the

I am trying to employ the ABCD optimization pass to remove unnecessary branches in the code my compiler generates. But in its current form (yesterday's trunk) the pass changes the behavior of the code such that execution yields invalid results, which is obviously not what I want. The switch in the following listing is used to implement a virtual method call, 99999 and 100000 are type

Thanks for noticing this, Geoff. I just landed r268050 which add a cmake option for this (and unifies XDEBUG and EXPENSIVE_CHECKS). This might make it easier to setup some build bots. Thank you, Filipe On Fri, Apr 22, 2016 at 8:40 PM, Geoff Berry via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Bugs filed: > 27488 <https://llvm.org/bugs/show_bug.cgi?id=27488> librarie

On Sat, Oct 14, 2017 at 11:05 AM, John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > These are definitely LLVM bugs. It would be best to report reduced test > cases against top of tree. > > We should have some automated infrastructure for finding these too... > > John > Zhendong & friends generally do that (and reported many bugs :) I tried that myself,

TL;DR This RFC is a joint effort by Intel and Saarland University to bring the divergence analysis of the Region Vectorizer [1,2,3,4,5] (dubbed the vectorization analysis of RV) to LLVM. The implementation is available on github for feedback [0]. The existing divergence analysis infrastructure in LLVM has conceptual limitations (structured control, SCEV based). The new analysis resolves bugs

On Thu, 16 Mar 2006, Eric Kidd wrote: > Hello! I'm compiling code which uses pointers as iterators. For some > reason--probably a silly misunderstanding of the docs--I can't eliminate > duplicate pointer loads. I'll probably figure this out eventually, but if > somebody else sees the answer instantly, I certainly won't complain. :-) There are no stupid questions.

Yeah, they are just triggered by lit check tests. I’ll file some bugs today, though it looks like Quentin may have already filed bugs for some of these. -- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Friday,

Hi Tobias, Thanks a lot for the detailed reply. I am working on several new optimizations for OpenCL kernels for a DSP architecture. The project itself has an NDA associated with it, so I cannot go into more details, but the source will be open to public after completion. One of the first steps is to serialize the work-items in a work-group (e.g., insert nested loops around REGIONs in

Hello! I'm compiling code which uses pointers as iterators. For some reason--probably a silly misunderstanding of the docs--I can't eliminate duplicate pointer loads. I'll probably figure this out eventually, but if somebody else sees the answer instantly, I certainly won't complain. :-) Here are the optimizers I'm running: opt -f -simplifycfg -dce -instcombine

On Sat, Oct 14, 2017 at 10:58:17PM -0500, Kavon Farvardin via llvm-dev wrote: > > something simpler will do, IMHO. Happy to discuss this further if > > folks are in California next week :) > > Yes, I'll be in California next week, let's chat! > > We could make use of the autotuner I'm currently building: > > https://github.com/kavon/autotune > >

Is there a way (without writing a pass to manually copy the block, etc) to eliminate this type of CFG creation? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120403/c00c377d/attachment.html>

hi Ryan, Any example? best regards ether On Wed, Apr 4, 2012 at 9:27 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Is there a way (without writing a pass to manually copy the block, etc) to > eliminate this type of CFG creation? > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu

Hi Tobi, I have one additional question about the RegionInfo::isRegion function. In the second case (i.e. Entry dominates Exit), why is checking the following two conditions are equivalent to checking it's a refined region: For any BB in DF(exit), 1) BB should be in DF(entry) 2) BB reachable only from entry through a path passing exit.

Hi all, While developing compile-time instrumentation for ThreadSanitizer (http://code.google.com/p/data-race-test) I need to generate SEME regions without loop and call instructions (I'll call them superblocks hereafter, although some researchers do allow loops in their definition of superblocks). This is necessary to get the largest piece of IR in which the memory operations can be

Hi all, I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project! Is there any comment or advice about my proposal? I appreciate all your help and advice. Thanks, Star Tan Proposal:

Tobias, Thanks for taking the time to summarize all this. It's a great writeup. I'm moving the thread to llvm-dev. My responses below. On May 21, 2012, at 5:06 AM, Tobias Grosser <tobias at grosser.es> wrote: > First of all some information about the RegionInfo pass: > > ======================================================================= > The very first paper I

On 04/26/2013 05:08 AM, tanmx_star wrote: > Hi all, Hi, thanks for the update and sorry for the delay in reviewing. I just had a look at your proposal. > I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project!