similar to: Questions about jump threading optimization and what we can do

Holy crap, I completely missed that. I'm sorry! That's my fault. On Sun, Feb 2, 2020 at 12:15 PM Johannes Doerfert <jdoerfert at anl.gov> wrote: > On 01/30, Karl Rehm via llvm-dev wrote: > > Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679 > I've > > been thinking about cases like it, such as: https://godbolt.org/z/Fwq8mn > > >

How does the code you would like to have look like? I don't see a relevant difference compared to gcc: https://godbolt.org/z/F-oah4 (clang unnecessarily introduces another temporary register, but that seems unrelated) Michael Am So., 2. Feb. 2020 um 18:24 Uhr schrieb Karl Rehm via llvm-dev <llvm-dev at lists.llvm.org>: > > Here's a better example. https://godbolt.org/z/fpTyFS

I am not convinced this is a jump-threading issue, but in the domain of ScalarEvolution. ScEv would need to find out which of the exits are taken or whether it loops infinitely. One can see that it exits after 10000 iterations, but ScalarEvolution cannot tell: https://godbolt.org/z/dCqdvv Michael Am Mo., 3. Feb. 2020 um 11:56 Uhr schrieb Karl Rehm <klrehm123 at gmail.com>: > > Well

Wait, you used the same example as I did. I'm confused then; if ScEv is having troubles but it still gets optimized away somewhere, what do you think is doing it? On Mon, Feb 3, 2020 at 2:16 PM Karl Rehm <klrehm123 at gmail.com> wrote: > Ah, I see. I think there's something else going on here too, though. > https://godbolt.org/z/dCqdvv is optimized away but ScEv doesn't

Hm. I assumed that JumpThreading would be the primary factor in optimizing code like this. Guess not. I'll need to look into SimplifyCFG to see what prevents it from doing the same thing to the other loop: https://godbolt.org/z/F6NjdG On Mon, Feb 3, 2020 at 3:09 PM Michael Kruse <llvmdev at meinersbur.de> wrote: > I assumed the LLVM-IR behind the godbolt link represented the C code

It's not about the pointer per se but the object it points to. If we have 2 objects of which we know the minimal/maximal size respectively we can sometimes conclude the objects must be different. Accesses to different objects do not alias. We already use that logic but we don't have the upper bound size as an attribute. Hence, it only applies if we know the exact size, basically is we see

On 01/28, Karl Rehm wrote: > > > > I need to take a closer look but I would have expected BasicAA to be > > able to determine that `do_log` and `R` cannot alias. In the -Os version > > (lower right here https://gcc.godbolt.org/z/KLaeiH), the write to `R` > > clobbers the read from `do_log` which prevents us from removing the > > load/store pair. My reasoning

Interesting, so I guess we can check for whether it's an array type and adjust accordingly instead? Blocking *all* global variables without definitive initializers feels a bit much to me, especially if they have primitive types (i.e. integers) that don't have the potential to be screwed around with like this. On Wed, Jan 29, 2020 at 8:14 PM George Burgess IV < george.burgess.iv at

Hi Karl, Roman, On 01/28, Roman Lebedev via llvm-dev wrote: > On Tue, Jan 28, 2020 at 8:09 PM Karl Rehm via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I was looking into how the global optimization pass fares against > > things like what's reported in > > https://bugs.llvm.org/show_bug.cgi?id=44676 I need to take a closer look but I would have expected

Hey everyone, I was looking into how the global optimization pass fares against things like what's reported in https://bugs.llvm.org/show_bug.cgi?id=44676 Looking at this, I think it would be pretty trivial to optimize that down given that there are already threading assumptions made: https://godbolt.org/z/u6ZqoB Is this something I can look into? Another thing is that currently *all* external

In this function (used to check the size of a global) there is an initial check for whether the initializer to this function is "definitive." My question is: why do we need this? How does the object's size change if a global's initializer is defined at link time? Thanks, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello everybody, I just started implementing a part of my algorithm that deals with irreducible control-flow. Apparently, the LoopInfo analysis does not recognize loops with multiple incoming edges (as of LLVM 2.5). On the mailing list archives I found a few discussions related to irreducible control-flow, but it was never mentioned if it is planned to enhance LoopInfo to also represent such

It seems that tail duplication can make a reducible CFG irreducible (example below). Is that intentional? Are there other optimizations that have that property? Is irreducibility a problem for existing LLVM passes? It looks like there was once an open project for a pass to make irreducible graphs reducible. Was that ever implemented? - Mark ; "opt -inline -tailduplicate" makes an

Hey, Thank you for your replies, Chris and Dan. Chris Lattner wrote: >> I am considering writing a patch for LoopInfo instead of creating my own >> data structure for irreducible loops. >> Is such an enhancement desired or even already implemented by someone >> (e.g. in the 2.6 branch)? > I'm not sure that this is a good idea. LoopInfo is clearly defined to >

On Thu, Jul 24, 2008 at 2:00 PM, Mark Leone <markleone at gmail.com> wrote: > Is irreducibility a problem for existing LLVM passes? There aren't any LLVM passes that expect a reducible CFG at the moment; of course, some passes are more effective with reducible CFGs. > It looks like > there was once an open project for a pass to make irreducible graphs > reducible. Was that

On Sep 28, 2009, at 2:28 AM, Ralf Karrenberg wrote: > Hello everybody, > > I just started implementing a part of my algorithm that deals with > irreducible control-flow. > Apparently, the LoopInfo analysis does not recognize loops with > multiple > incoming edges (as of LLVM 2.5). > On the mailing list archives I found a few discussions related to > irreducible

Hi everyone, I'm currently trying to run a study on irreducibility of C programs, and I've implemented structural analysis (original paper by Sharir, algorithm in Muchnick's book) as an LLVM pass. When my implementation becomes a bit less buggy I'll certainly look into including it in the LLVM project. As a test for the algorithm I've been producing LLVM bitcode for C files

Hi Georg, > one question with regard to a Powerware 5115 UPS connected to a Debian 3.1 > Sarge box via USB: I downloaded and compiled nut 2.0.2 but I am unable to > configure the USB subsystem so that upsdrvctl recognizes the UPS. > > My /usr/local/ups/etc/ups.conf contains: > > [bla] > driver = bcmxcp > port = /dev/usbdev2.2 > desc = "bla bla

Hello, I'm wondering how exactly LLVM deals with passes that open up opportunities for other passes. For example, InstCombine says that it opens many opportunities for dead code/store elimination. However, the reverse may also be true. How does LLVM currently handle this? -------------- next part -------------- An HTML attachment was scrubbed... URL:

We would like to develop a code generator using LLVM for a target language that does not support conditional branches and in fact only supports structured control flow, eg. If and while. As far as I can tell that the problem with doing this in LLVM today, is that it does not support these high-level constructs and instead all control flow is implemented as branches. It is ³fairly²