search for: rl285729

...vm-dev at lists.llvm.org>; John Regehr <regehr at cs.utah.edu>; 3.14472+reviews.llvm.org at gmail.com Subject: Re: [llvm-dev] Alive now available online Hi Nuno, This is great. I just stumbled onto a problem that's similar to the one that Bryant solved in: https://reviews.llvm.org/rL285729 define i1 @foo(i32 %x) { %shl = shl nsw i32 %x, 4 %cmp = icmp sgt i32 %shl, 1 ret i1 %cmp } (For more background, see PR30773 - https://llvm.org/bugs/show_bug.cgi?id=30773 ) So I'm staring at that wondering why instcombine can't see that it's really just: define i1 @foo(i32...

Hi, Just a short email to announce that Alive is now available online: http://rise4fun.com/Alive The site includes a few examples (both correct and buggy). You can also create a "permalink" to send the proof to someone else. The execution time is limited to 30 seconds for now. You may want to constrain the operand's types if the tool times out, for example. The service is

...72+reviews.llvm.org at gmail.com >> *Subject:* Re: [llvm-dev] Alive now available online >> >> >> >> Hi Nuno, >> >> This is great. I just stumbled onto a problem that's similar to the one >> that Bryant solved in: >> https://reviews.llvm.org/rL285729 >> >> define i1 @foo(i32 %x) { >> %shl = shl nsw i32 %x, 4 >> %cmp = icmp sgt i32 %shl, 1 >> ret i1 %cmp >> } >> >> (For more background, see PR30773 - https://llvm.org/bugs/show_bug >> .cgi?id=30773 ) >> >> >> >> S...

...ecause the IR is now decidedly worse. > > IMO, we should not revert the commit because it exposed shortcomings in the optimizer. It's an "obvious" fold/canonicalization, and the related 'nuw' variant of this fold has existed in trunk since: > https://reviews.llvm.org/rL285729 <https://reviews.llvm.org/rL285729> > > We need to dissect what analysis/folds are missing to restore the IR to the better form that existed before, but this is probably going to be a long process because we treat min/max like an optimization fence. If this is gonna be a long process...

...R is now decidedly worse. >> >> IMO, we should not revert the commit because it exposed shortcomings in the optimizer. It's an "obvious" fold/canonicalization, and the related 'nuw' variant of this fold has existed in trunk since: >> https://reviews.llvm.org/rL285729 <https://reviews.llvm.org/rL285729> >> >> We need to dissect what analysis/folds are missing to restore the IR to the better form that existed before, but this is probably going to be a long process because we treat min/max like an optimization fence. > > If this is gonna...

Confirm there is no change in IR if the hack is disabled in the sources. David wrote that these instructions are created by SCEV. Are other targets affected by the changes, e.g. X86? Kind regards, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Sunday, January 22, 2017 10:45 PM To: Evgeny Astigeevich Cc: llvm-dev; nd

...nted out here because the IR is now decidedly worse. IMO, we should not revert the commit because it exposed shortcomings in the optimizer. It's an "obvious" fold/canonicalization, and the related 'nuw' variant of this fold has existed in trunk since: https://reviews.llvm.org/rL285729 We need to dissect what analysis/folds are missing to restore the IR to the better form that existed before, but this is probably going to be a long process because we treat min/max like an optimization fence. If this is gonna be a long process to recover, this looks like something to be reverted...