similar to: [LLVMdev] RFC: Proposal to Remove Poison

Today I ran into another aspect of the poison problem... Basically, SimplifyCFG wants to take expr1 && expr2 and flatten it into x = expr1 y = expr2 x&y This isn't safe when expr2 might execute UB. The consequence is that no LLVM shift instruction is safe to speculatively execute, nor is any nsw/nuw/exact variant, unless the operands can be proven to be in

Hello, What follows is my attempt to describe how poison works. Let me know what you think. -- David # LLVM Poison Semantics Poison is an LLVM concept which exists solely to enable further optimization of LLVM IR. The exact behavior of poison has been, to say the least, confusing for users, researchers and engineers working with LLVM. This document hopes to clear up some of the confusion

On 01/28/2015 07:02 AM, Sean Silva wrote: > Could you maybe provide an example where replacing `%always_poison` > with `undef` will change the meaning? At least for me, the thing that > I'm most unclear about is how poison differs from undef. I will second this request for much the same reason. > > -- Sean Silva > > On Wed, Jan 28, 2015 at 2:50 AM, David Majnemer >

On Sun, Feb 8, 2015 at 8:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > Currently, we might replace: > %cmp = icmp sgt i32 undef, INT_MAX -> i1 false > > According to this proposal, we could replace: > %cmp = icmp sgt i32 undef, INT_MAX -> i1 undef > > While replacing it with false is still allowed, so is replacing it with > true. I'm not sure this

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

Hello to everybody, I'm working on some improvements on trip count computation with ScalarEvolution analysis. Considering the following test ;----------------------------------------------------------------------------; define void @foo(i32 %a, i32 %b, i32 %s) #0 { entry: %cmp = icmp sgt i32 %s, 0 %cmp15 = icmp sgt i32 %a, %b %or.cond = and i1 %cmp, %cmp15 br i1 %or.cond, label

Hi, InstCombine canonicalizes index operands (unless they are into struct types) to pointer size. The comment says: "If we are using a wider index than needed for this platform, shrink it to what we need. If narrower, sign-extend it to what we need. This explicit cast can make subsequent optimizations more obvious.". For our architecture, the canonicalization is a bit

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

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,

On Oct 1, 2013, at 6:45 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > Hello to everybody, > > I'm working on some improvements on trip count computation with ScalarEvolution > analysis. > Considering the following test > > ;----------------------------------------------------------------------------; > define void @foo(i32 %a, i32 %b, i32 %s) #0

On Sun, Feb 8, 2015 at 10:02 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > When you say, "we'd like to", I'm assuming your justification for this is > so that we can model poison using these undef semantics. Is that correct? > Yes, but I also think 'icmp sgt i32 undef, %a -> i1 undef' is a pretty reasonable transform by itself. Well-defined programs

Hello all, I just noticed that LLVM has trouble recognizing nested simple select operations. My testcase is as follows: -------------------------- snip ------------------------------ #include <stdio.h> int main(int argc, char **argv) { int a; scanf("%d", &a); a = a > 255 ? 255 : a < 0 ? 0 : a; printf("A: %d\n", a); return 0; }

I'd missed the fact that j wasn't just being decremented. This isn't as easy as I said. Philip On 03/03/2016 02:36 PM, Philip Reames via llvm-dev wrote: > SCEV should be able to easily prove that j is positive here. I'm not > sure where the right place to use that information would be in this > case. Sanjoy, can you comment? > > Philip > > On 03/03/2016

We have several optimizations in InstCombine for bitwise logic ops (and/or/xor) that fail to handle compare patterns with the equivalent bitwise logic. Example: define i8 @or_and_not(i8 %a, i8 %b) { %nota = xor i8 %a, -1 %and = and i8 %nota, %b %res = or i8 %and, %a ret i8 %res } define i1 @or_and_cmp_not(i32 %a, i32 %b, i1 %c) { %cmp = icmp sgt i32 %a, %b %cmp_inv = icmp sle i32 %a,

Hi all, I met the error while compiling the code with vector type with some architecture. IR is as following. %cmp = icmp sgt <3 x i8> %x, zeroinitializer %sub = sub <3 x i8> zeroinitializer, %x %cond = select <3 x i1> %cmp, <3 x i8> %x, <3 x i8> %sub 'select' IR is converted to 'vselect' dag and is combined to 'sra (X, size(X)-1); xor

Hi Sebpop, Thanks for your explanation. I noticed that Polly would finally run the SROA pass to transform these load/store instructions into scalar operations. Is it possible to run such a pass before polly-dependence analysis? Star Tan At 2013-08-15 21:12:53,"Sebastian Pop" <sebpop at gmail.com> wrote: >Codeprepare and independent blocks are introducing these loads and

This can't be an instsimplify though? The values we want in these cases do not exist already: %res = or i8 %b, %a %res = or i1 %cmp, %c On Thu, Jul 13, 2017 at 5:10 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Thu, Jul 13, 2017 at 2:12 PM, Sanjay Patel <spatel at rotateright.com> > wrote: > >> We have several optimizations in InstCombine

Hi all, I have a question regarding a transformation that is carried out in InstCombine, which has been introduced by r48715. It unfolds expressions of the form `zext(or(icmp, (icmp)))` to `or(zext(icmp), zext(icmp)))` to expose pairs of `zext(icmp)`. In a subsequent iteration these `zext(icmp)` pairs could then (possibly) be optimized by another optimization (which has already been there before

Hi all, I have investigated the 6X extra compile-time overhead when Polly compiles the simple nestedloop benchmark in LLVM-testsuite. (http://188.40.87.11:8000/db_default/v4/nts/31?compare_to=28&baseline=28). Preliminary results show that such compile-time overhead is resulted by the complicated polly-dependence analysis. However, the key seems to be the polly-prepare pass, which introduces

Codeprepare and independent blocks are introducing these loads and stores. These are prepasses that polly runs prior to building the dependence graph to transform scalar dependences into data dependences. Ether was working on eliminating the rewrite of scalar dependences. On Thu, Aug 15, 2013 at 5:32 AM, Star Tan <tanmx_star at yeah.net> wrote: > Hi all, > > I have investigated the