search for: godbolt

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 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? &...

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

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 > you used before. > > SimplifyCFG actually helps the loop being removed: > https://godbolt.org/z/5v7SXh > &gt...

...d. 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 meinersbur.de> > wrote: > >> I am not convinced this is a jump-threading issue, but in the domain >> of Scala...

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 don't know...

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; > V.push_back(0); > return V; > } > ``` > I think...

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: x64 msvc v19.0 (WINE)". > > Your sample compiles fine with it: https://godbolt.org/z/hsPneK > > > Als...

...return expected > values > > > > 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: x64 msvc v19.0 (WINE)". >> >> Your sample compiles fine with it: https://godbolt.org...

...st that storing an aggregate fills padding with undef. Here are a few clues that supports this change: - According to C17, the value of padding bytes when storing values in structures or unions is unspecified. - IPSCCP ignores padding and directly stores a constant aggregate if possible: https://godbolt.org/z/ddWq9z Memcpyopt ignores padding when copying an aggregate or storing a constant: https://godbolt.org/z/hY6ndd / https://godbolt.org/z/3WMP5a - Alive2 (with store operation updated) did not find any problematic transformation from LLVM unit tests and while running translation validation on a...

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

...... But the wierd thing here is if I change the array to be of size 256 and the index to be 'unsigned char', seems like there is no way to access the 'size' field throught "y->ptr[index]" (in your example) but clang still performs the re-read: <a href="https://godbolt.org/z/ahlGHY">https://godbolt.org/z/ahlGHY</a><br /><br /></div> <div dir="ltr">It looks like clang sees an alias between "int ptr[256]" and "int size"... maybe because they are both "int"? Because changing the type of si...

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

...(const RuntimeDyld::JITObject::Section& S : JO.sections()) if (S.isText()) Disassemble(S.getAddr(), S.getSize()); ); How does that look? Cheers, Lang. On Wed, Sep 17, 2014 at 3:08 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 09/17/2014 12:45 PM, Matt Godbolt wrote: > >> Great stuff; thanks both! >> >> I'm also looking to turn my MCJIT conversion spike into our main use >> case. The only thing I'm missing is the ability to get a post-linked >> copy of the generated assembly. >> >> In JIT I used JITEve...

...rget CPU when you create the JIT. It’s just a method on the builder (e.g., builder.setMCPU(MCPU)). If you want auto-detection based on the host CPU, sys::getHostCPUName() returns a value suitable to be passed directly into the builder. > > -Jim > >> On Sep 17, 2014, at 11:44 AM, Matt Godbolt <matt at godbolt.org> wrote: >> >> Hi guys, >> >> I just upgraded our JIT system to use llvm 3.5 and noticed one big >> change in our generated code: we don't see any non-destructive VEX >> prefix instructions being emitted any more (vmulsd xmm0, xmm1,...

"Tim Northover" <t.p.northover at gmail.com> wrote: > Hi Stefan, > > On Mon, 26 Nov 2018 at 12:37, Stefan Kanthak via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> LLVM/clang generates wrong code for the following program >> (see <https://godbolt.org/z/UZrrkG>): > > It looks like all of these issues come down to mismatched expectations > on what goes into and out of an __asm block. If you look at the MSVC > documentation (which I think Clang is trying to be compatible with), > it warns against assuming known values are in...

...struct st1 obj1; struct st2 obj2; }Obj; int test1(struct st1 * ptr1 , struct st2 * ptr2, struct st2 *ptr3) { ptr1->a = 10; *ptr3 = *ptr2; return ptr1->a; } --Snip--- For the above case GCC is able to store forward the value 10 to the return place. LLVM is not doing this. GCC https://godbolt.org/z/FCjCXy LLVM https://godbolt.org/z/TFgnig My understanding is that under strict aliasing rules accessing objects of different types don't alias. In this case we are accessing "struct st2" object and "int" type object. so aliasing should not prevent the forwarding of s...

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 would have been that we know the size of > > `do_log` to be less than the size accessed via `R`. What exactly goes > > wrong or if my log...

...mization 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 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 would have been that we know the size of `do_log` to be less than the size accessed via `R`. What exactly goes wrong or if my logic is flawed needs to be examined. I wou...

...sult to > createTargetMachine() passed to the JIT. This patch should be applied: > > http://llvm.org/bugs/show_bug.cgi?id=17422 > > Anyhow, the JIT was removed from current code and will not be in next LLVM > release. > > Yaron > > > 2014-09-17 22:27 GMT+03:00 Matt Godbolt <matt at godbolt.org>: >> >> Hi Jim, >> >> Thanks for a very quick reply! That indeed does the trick! >> >> Presumably the default has changed in 3.5 to be a "generic" CPU >> instead of the native one? If that's the case I wonder why: es...

On Mon, Jun 6, 2016 at 12:11 PM, Matt Godbolt <matt at godbolt.org> wrote: > > On Mon, Jun 6, 2016 at 1:41 PM Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> As to leave an opportunity for the kernel, I think mmap+write would be >> enough. Because the kernel knows what address is mmap...