similar to: Global removal pass - potential for improvement?

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

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

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

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

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

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

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

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 I wonder what we can do about this in a general sense. As far as I can tell, the jump threading algorithm is *really* conservative, which is one reason this isn't working as well as I'd hope; however, we don't want to produce

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

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:

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

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:

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

_mm_lfence was originally documented as a load fence. But in light of speculative execution vulnerabilities it has started being advertised as a way to prevent speculative execution. Current Intel Software Development Manual documents it as "Specifically, LFENCE does not execute until all prior instructions have completed locally, and no later instruction begins execution until LFENCE

On Thu, Oct 31, 2019 at 11:17 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Oct 31, 2019 at 8:50 AM kamlesh kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Devs, >> Consider testcase here >> https://godbolt.org/z/qHZzqw >> When optimization is O1 or above it produces unoptimized code >> because it

Hi, I think I found a minor bug in OpenSSH's log functionality: If a log message which is larger than MSGBUFSIZE=1024 and logged to stderr, then the newline (\r\n) is not printed. This is due to the fact that the newline is added after the log message concatenated with "\r\n" is snprintf'd to another buffer of the same size. If the source buffer (fmtbuf) would already fill the

On Thu, Oct 1, 2020 at 2:08 AM George Rimar <grimar at accesssoftek.com> wrote: > FWIW, I've performed an experiment with the code below at godbolt. > (used -O2, https://godbolt.org/z/nY95nh) > > ``` > #include <vector> > #include "llvm/Support/Error.h" > > llvm::Expected<std::vector<int>> foo() { > std::vector<int> V; >

Hi Devs, Consider testcase here https://godbolt.org/z/qHZzqw When optimization is O1 or above it produces unoptimized code because it calls __tls_get_address in loops. While with optimization disabled It produce single call to __tls_get_address outside of loop. is this a missed optimization by llvm? ./Kamlesh

On Fri, Oct 2, 2020 at 1:48 AM George Rimar <grimar at accesssoftek.com> wrote: > Thanks, David! > > > Few minor additions to the topic: > > > > I'm not sure which MSVC version on godbolt would be "MSVC 2017" that > the LLVM docs refer to > > > I've found that the minimal available version of MSVC on > godbolt is "WINE MSVC 2015:

Yeah, not sure either. The discussion about minimum compatibility usually comes down to what version is available on long-term OS releases. On Fri, Oct 2, 2020 at 12:38 PM George Rimar <grimar at accesssoftek.com> wrote: > > Is the code currently broken? > > > I don't know. Perhaps the code is fine, I did not try to compile LLVM > with all that compilers > >