similar to: RFC: alive.llvm.org?

No concerns from me. I use Alive2 all the time, and it would be fantastic to have it available online reliably. If we can get Alive1 up there too, that would be even better. I still use that to try to prove things where it's not obvious how to express the relationships in pure LLVM IR: https://rise4fun.com/Alive/NDu On Wed, Jun 17, 2020 at 4:05 PM Chris Lattner via llvm-dev < llvm-dev at

+1 to alive2.llvm.org On Thu, Jun 18, 2020 at 8:11 AM John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > If we can get Alive1 up there too, that would be even better. I still > > use that to try to prove things where it's not obvious how to express > > the relationships in pure LLVM IR: > > https://rise4fun.com/Alive/NDu > > I don't

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

Not sure how off-topic this is, but should we consider/have we considered porting our InstCombines to Alive? The PLDI '15 paper even demos C++ extraction from Alive theorems. I think it'd be a small step from that to extracting tightly optimized VM code, not unlike what Tablegen emits. Everything would be so clean and readable and organized. And edge cases can still be handled manually,

Hi Sanjay, You used Alive correctly, of course :) At this moment we cannot give you the best precondition. It’s on the todo list, but it’s not even started yet. It’s a much harder problem to solve. We do have a mode to compute the best set of nsw/nuw/exact attributes in the transformed expression, but it’s not enabled on the web interface yet (InstCombine was missing quite a few cases last

Sorry, we really screwed up the server migration. Alive is now working again and should be fixed for good :) Permalinks are still missing; we are working on recovering those. Apologies again for all the trouble. Nuno -----Original Message----- From: Sanjay Patel Sent: Monday, October 2, 2017 5:10 PM Subject: Re: [llvm-dev] Where did Alive go? I still can't use the web app - spins for

Craig I know it's a pain compared to the web interface but Alive is pretty easy to install and run from a shell. John On 9/22/17 11:41 AM, Craig Topper via llvm-dev wrote: > And now rise4fun.com <http://rise4fun.com> doesn't work at all? > > ~Craig > > On Wed, Sep 20, 2017 at 9:53 AM, Nuno Lopes <nunoplopes at sapo.pt > <mailto:nunoplopes at

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

Hi, We're looking at what may be a real-life bug encountered by our compiler related to `undef` values and function calls. The input program effectively contains the expression clamp(v, x, x) expecting that the result will be equal to `x`, even when `v` is read from uninitialized memory. In the input language, `clamp` is a built-in, so this expectation is somewhat reasonable. In our

And now rise4fun.com doesn't work at all? ~Craig On Wed, Sep 20, 2017 at 9:53 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Alive is now working again. There was a migration to a new server. > Permalinks are still being copied from backup; they will work again > shortly as well. (I would probably not create new ones since they may get > replaced while the copy is in

There's a question about the behavior of funnel shift [1] + select and poison here that reminds me of previous discussions about select and poison [2]: https://github.com/AliveToolkit/alive2/pull/32#discussion_r257528880 Example: define i8 @fshl_zero_shift_guard(i8 %x, i8 %y, i8 %sh) { %c = icmp eq i8 %sh, 0 %f = fshl i8 %x, i8 %y, i8 %sh %s = select i1 %c, i8 %x, i8 %f ; shift amount is 0

We have these transforms from funnel shift to a simpler shift op: // fshl(X, 0, C) -> shl X, C // fshl(X, undef, C) -> shl X, C // fshl(0, X, C) -> lshr X, (BW-C) // fshl(undef, X, C) -> lshr X, (BW-C) These were part of: https://reviews.llvm.org/D54778 In all cases, one operand must be 0 or undef and the shift amount is a constant, so I think these are safe.

If I got poison propagation right, it's probably only by luck! Hopefully, the funnel shift bug is fixed here: https://reviews.llvm.org/rL354905 Nuno, IIUC this means that you do *not* need to change the funnel shift semantics in Alive. So I think that means we're still on track to go with John's suggestion that only select and phi can block poison? (I don't know of any

Hi, This is a follow up on a discussion around shufflevector with undef mask in https://reviews.llvm.org/D70641 and https://bugs.llvm.org/show_bug.cgi?id=43958. The current semantics of shufflevector in http://llvm.org/docs/LangRef.html#shufflevector-instruction states: "If the shuffle mask is undef, the result vector is undef. If any element of the mask operand is undef, that element

Hi, Let me try to give a bit more context on why select is so tricky. First thing to consider is which transformations we would like to support: 1) Control-flow -> select (SimplifyCFG) if (c) a = x else a = y => %a = select %c, %x, %y 2) select -> control-flow; reverse of 1) Not sure if this is done at IR level, or only later at SDAG. 3) select ->

Regarding the patches, there are two concerns AFAICT: 1. It’s a new instruction and as usual when introducing a new instruction it will require work for some time until most optimizations know about it, and to get rid of any potential perf regression. No big deal; we just need to do the work (and we have already done some of it). 2. The patch was written by a student, which may not have time to

I came across this comment in SelectionDAG.cpp: case ISD::FADD: case ISD::FSUB: case ISD::FMUL: case ISD::FDIV: case ISD::FREM: // If both operands are undef, the result is undef. If 1 operand is undef, // the result is NaN. This should match the behavior of the IR optimizer. That isn't intuitive to me. I would have expected a binary FP operation with one undef operand to

Some InstCombine transforms for select-of-select were added here: https://reviews.llvm.org/rL228409 But Alive says this is more poisonous: Name: selsel %s1 = select i1 %cond1, i8 C1, i8 C2 %s2 = select i1 %cond2, i8 %s1, i8 C2 => %andcond = and i1 %cond1, %cond2 %s2 = select i1 %andcond, i8 C1, i8 C2 http://rise4fun.com/Alive/JT6 Are those transforms legal? -------------- next part

Don't we need to distinguish funnel shift from the more specific rotate? I'm not seeing how rotate (a single input op shifted by some amount) gets into trouble like funnel shift (two variables concatenated and shifted by some amount). Eg, if in pseudo IR we have: %funnel_shift = fshl %x, %y, %sh ; this is problematic because either x or y can be poison, but we may not touch the poison when

You are right: select in SDAG has to be poison-blocking as well, otherwise the current lowering from IR's select to SDAG's select would be wrong. Which makes the select->or transformation incorrect at SDAG level as well. I guess until recently people believed that poison in SDAG wasn't much of a problem (myself included). I was convinced otherwise with the test cases that