search for: klrehm123

...n 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 ideally it'd do the same thing as before (with two if statements). Something like: > ret i64 4 > > It's not really about needing to be as good as gcc, it's more that I wonder why the same concept with just two if-else blocks gets optimized yet m...

...Rehm via llvm-dev <llvm-dev at lists.llvm.org>: > > Here's a better example. https://godbolt.org/z/fpTyFS > I don't know what exactly you would need to change in JumpThreading to improve this, but I'm open to ideas. > > On Sun, Feb 2, 2020 at 12:45 PM Karl Rehm <klrehm123 at gmail.com> wrote: >> >> 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: >>> &...

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

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 know > whether this loop terminates either. > > On Mon, Feb 3, 2020 at 1:36 PM Michael Kruse <llvmdev at meiner...

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 > > >

...e link I included before. I don't know what you mean by llvm being a generic backend but what I describe above and in the tutorial should make it in as soon as the code is cleaned up. It's on my GitHub already. -- written from my phone ________________________________ From: Karl Rehm <klrehm123 at gmail.com> Sent: Tuesday, January 28, 2020 12:42:33 PM To: Doerfert, Johannes <jdoerfert at anl.gov> Cc: Roman Lebedev <lebedev.ri at gmail.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Global removal pass - potential for improvement?...

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

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