similar to: A bug related with undef value when bootstrap MemorySSA.cpp

On 07/18/2017 06:03 PM, David Majnemer via llvm-dev wrote: > I doubt it is possible for us to try and make any fix which is > predicated on eagerly treating undef in a particular way, refinement > will always cause these problems to come about... > > Given what I've seen in LLVM (and what I've learned from other > compilers), we probably have two choices: > 1.

Hello, some of the patches had conflicts with LLVM head, so I updated them. If you experienced patch failure before then you can try it again. I compiled your code (1.c) with LLVM r308173 with the 5 patches applied, and it generated assembly like this. Now it contains store to c(%rip). It tries to store a(%rip) + b(%rip) to c(%rip). I wish this translation is now correct. ``` 73 .globl hoo

It seems MemorySSA.cpp is the only real code where we found the problem happening. Is it possible to change the source of MemorySSA.cpp to hide the problem and buy some time for now? Now we use an empty generic_def_path_iterator with Optional<ListIndex> N being initialized by None as the end of range. Can we initialize the Optional var with a special value instead of None?

Hi, On Mon, Jul 17, 2017 at 1:56 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Mon, Jul 17, 2017 at 1:53 PM, Wei Mi <wmi at google.com> wrote: >> >> It seems MemorySSA.cpp is the only real code where we found the >> problem happening. > > > This is doubtful, ¸FWIW :) > >> >> Is it possible to change the

On Mon, Jul 17, 2017 at 5:11 PM, Wei Mi <wmi at google.com> wrote: > On Mon, Jul 17, 2017 at 2:09 PM, Sanjoy Das > <sanjoy at playingwithpointers.com> wrote: >> Hi, >> >> On Mon, Jul 17, 2017 at 1:56 PM, Daniel Berlin via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> On Mon, Jul 17, 2017 at 1:53 PM, Wei Mi

On Mon, Jul 17, 2017 at 11:18 AM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Mon, Jul 17, 2017 at 10:32 AM, Xinliang David Li <davidxl at google.com> > wrote: > > The issue blocks another optimization patch and Wei has spent huge > amount of > > effort isolating the the bootstrap failure to this same problem. I agree > >

Cool, thanks for debugging this issue and letting us know. We have a few patches to fix this issue: - Introduce freeze in IR: https://reviews.llvm.org/D29011 - Lowering freeze: https://reviews.llvm.org/D29014 - Fix loop unswitch: https://reviews.llvm.org/D29015 Bonus patches to recover perf: - Be less conservative in loop unswitching: https://reviews.llvm.org/D29016 - Instcombine support

The issue blocks another optimization patch and Wei has spent huge amount of effort isolating the the bootstrap failure to this same problem. I agree with Wei that other developers may also get hit by the same issue and the cost of leaving this issue open for long can be very high to the community. David On Mon, Jul 17, 2017 at 10:01 AM, Wei Mi <wmi at google.com> wrote: > Sanjoy and

Hi, I wanted to give a heads-up that I've been looking into replacing the AliasSetTracker(AST) with MemorySSA in the Loop Invariant Code Motion (LICM) pass. I would love to get feedback on the best way to incrementally push in this change. Motivation: There has been an outstanding issue with using the Alias Set Tracker due to its expensive construction time (quadratic). We've had test

Hi guys, I was looking at the thread creation API. Exactly, why do we use PTHREAD_SCOPE_SYSTEM instead of PTHREAD_SCOPE_PROCESS ? http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ntdll/thread.c#l611 What is the technical difference? I remember, some years ago, that on SunOS 8 setting the latter it would make one thread only scheduled globally for the process, instead, using the first would

That's an unintentional change. However, the reason for this change was to make optional of trivially copyable types trivially copyable, adding a user-provided move ctor would break that again :( I'm leaning towards making the non-trivial version of llvm::Optional more like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

On Wed, Jan 24, 2018 at 11:47 PM, Benjamin Kramer <benny.kra at gmail.com> wrote: > That's an unintentional change. However, the reason for this change > was to make optional of trivially copyable types trivially copyable, > adding a user-provided move ctor would break that again :( > > I'm leaning towards making the non-trivial version of llvm::Optional > more

Hey Ben, This change broke some clangd code (no failing test, mea culpa), because it changed the move semantics. Previously: a moved-from llvm::Optional was None (for all types). Now: a moved-from llvm::Optional is None (for non-trivial types), and has the old value (for trivial types). FWIW, a moved-from std::optional is *not* nullopt, and contains the moved-from value. This seems sad to me,

For the example code below, int L = M + 10; for (k = 1 ; k <=L; k++) { dummy(); if (k < M) dummy2(); } , we can split the loop into two parts like : for (k = 1 ; k != M; k++) { dummy(); dummy2(); } for (; k <=L; k++) { dummy(); } By splitting the loop, we can remove the conditional block in the loop and indirectly increase vectorization

Hi all. By now loops with switch instruction are unswitched value-by-value. For example for case range [0..9] we need to run unswitch process 10 times! I want try to optimize that case. Is there any hidden problems that blocks this improvement? Regards, Stepan.

As came up recently in other threads, loop passes really get in the way. Here are some of the ways: - There is only one Loop analysis pass - IVUsers. It seems unlikely that the loop nest walk is critical to computing this or preserving it. - Almost all of the things we think of as "required" and dependencies are actually *transforms* that canonicalize the form of a loop into particular

On Fri, Feb 23, 2018 at 12:15 AM, Jun Lim via llvm-dev <llvm-dev at lists.llvm.org> wrote: > For the example code below, > int L = M + 10; > for (k = 1 ; k <=L; k++) { > dummy(); > if (k < M) > dummy2(); > } > , we can split the loop into two parts like : > > for (k = 1 ; k != M; k++) { > dummy(); > dummy2(); > }

Hi, I have a general question on LoopUnswtich pass. Consider the following IR snippet: define i32 @test(i1 %cond) { br label %loop_begin loop_begin: br i1 %cond, label %loop_body, label %loop_exit loop_body: br label %do_something do_something: call void @some_func() noreturn nounwind br label %loop_begin loop_exit: ret i32 0 } declare void @some_func() noreturn After running

Looks like there are many overloads for "get". http://llvm.org/doxygen/MemoryLocation_8cpp_source.html But nothing for CallInst. Any suggestions how to do a proper one? I will look at it too. 2018-05-22 23:34 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Full stack trace: > > opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T* >

On 2018-02-22 16:21, Roman Lebedev wrote: > On Fri, Feb 23, 2018 at 12:15 AM, Jun Lim via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> For the example code below, >> int L = M + 10; >> for (k = 1 ; k <=L; k++) { >> dummy(); >> if (k < M) >> dummy2(); >> } >> , we can split the loop into two parts like :