similar to: [LLVMdev] SCCP and undef branches

Nick Lewycky wrote: > I found that "undef" was disappearing early into the optimization chain. > SCCP was the culprit, transforming: > > br bool undef, label %T, label %F > > into > > br bool true, label %T, label %F > > While that sounds like a great optimization, it shouldn't be happening > that early. Uh, why?

Daniel Berlin wrote: > Nick Lewycky wrote: > >>I found that "undef" was disappearing early into the optimization chain. >>SCCP was the culprit, transforming: >> >> br bool undef, label %T, label %F >> >>into >> >> br bool true, label %T, label %F >> >>While that sounds like a great optimization, it shouldn't be

Chris Lattner wrote: > On Tue, 9 May 2006, Nick Lewycky wrote: > >>>> For an analysis pass, I'm interested in reading the lattice values >>>> calculated by SCCP. Should I split the current SCCP optimization >>>> into an >>>> analysis piece and the optimization that depends on it, so that I can >>>> use its analysis results?

On Tue, 9 May 2006, Nick Lewycky wrote: >>> For an analysis pass, I'm interested in reading the lattice values >>> calculated by SCCP. Should I split the current SCCP optimization into an >>> analysis piece and the optimization that depends on it, so that I can >>> use its analysis results? >> >> SCCP is already split into an SCCPSolver class

Chris Lattner wrote: > On Tue, 9 May 2006, Nick Lewycky wrote: > >> For an analysis pass, I'm interested in reading the lattice values >> calculated by SCCP. Should I split the current SCCP optimization into an >> analysis piece and the optimization that depends on it, so that I can >> use its analysis results? > > SCCP is already split into an SCCPSolver

On Tue, 9 May 2006, Nick Lewycky wrote: >> You could do that, but SCCPSolver isn't really useful to mainline LLVM >> for anything other than SCCP and IPSCCP, so we don't need it in a public >> header. Out of curiosity, what are you looking to use the latice values >> for? Why not just run SCCP and then look at the transformed code? > > I was planning to

On Tue, 9 May 2006, Nick Lewycky wrote: > For an analysis pass, I'm interested in reading the lattice values > calculated by SCCP. Should I split the current SCCP optimization into an > analysis piece and the optimization that depends on it, so that I can > use its analysis results? SCCP is already split into an SCCPSolver class that is used by the SCCP and IPSCCP classes. You

On Mon, Jan 2, 2017 at 2:24 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Davide, > > On Sat, Dec 31, 2016 at 4:19 AM, Davide Italiano <davide at freebsd.org> wrote: >> Although originally I wasn't, I'm increasingly convinced this is the >> right path forward (at least in the beginning), i.e. strip undef >> handling entirely. I tried

Chris Lattner wrote: > On Tue, 9 May 2006, Nick Lewycky wrote: > >>> You could do that, but SCCPSolver isn't really useful to mainline LLVM >>> for anything other than SCCP and IPSCCP, so we don't need it in a public >>> header. Out of curiosity, what are you looking to use the latice values >>> for? Why not just run SCCP and then look at the

Which transformation passes are 'safe', meaning it does not worsens the effectiveness of a later pass or the generated code? I imagine all passes which either removes data or add attributes are included in this list, plus some simplification passes: -adce -argpromotion -constmerge -constprop -deadargelim -dse -functionattrs -globaldce -globalopt -gvn -instcombine -internalize

For an analysis pass, I'm interested in reading the lattice values calculated by SCCP. Should I split the current SCCP optimization into an analysis piece and the optimization that depends on it, so that I can use its analysis results? Nick Lewycky

Hi David, Looking at the original bug, it seems like a straightforward undef-propagation bug to me -- SCCP was folding "or undef, constant" to "undef", which is wrong. Why is changing that not the fix? That is, some variant of diff --git a/lib/Transforms/Scalar/SCCP.cpp b/lib/Transforms/Scalar/SCCP.cpp index 8a6be97..45f1241 100644 --- a/lib/Transforms/Scalar/SCCP.cpp +++

On Fri, Dec 30, 2016 at 9:27 AM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi. > I'm sending this email to -dev as this may be of interest of > many/people may have opinions/want to try the change before it goes in > to report problems. > I've been recently working on a patch to integrate `undef` in the SCCP > solver, in the hope of fixing

On Fri, Dec 30, 2016, 9:04 PM Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi David, > > Looking at the original bug, it seems like a straightforward > undef-propagation bug to me -- SCCP was folding "or undef, constant" > to "undef", which is wrong. Why is changing that not the fix? That > is, some variant of > You would still

On Sat, Dec 31, 2016 at 12:15 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, Dec 30, 2016 at 11:55 PM, Sanjoy Das > <sanjoy at playingwithpointers.com> wrote: >> >> Hi Daniel, >> >> On Fri, Dec 30, 2016 at 10:55 PM, Daniel Berlin <dberlin at dberlin.org> >> wrote: >> >> Right, but we are talking about

Hi. I'm sending this email to -dev as this may be of interest of many/people may have opinions/want to try the change before it goes in to report problems. I've been recently working on a patch to integrate `undef` in the SCCP solver, in the hope of fixing a tail of latent bugs in SCCP which remained uncovered for many years. I think this is a decent time to propose, so that it can

Hi, Here's something I don't understand... How come that UNDEF can appear as a branch condition at all? I just can't think of any ways. If you write something like fun() { int x; if (x > 100) { ... } else { ... } } LLVM generates a boolean temporary that compares (uninitialized) value of x with 100. Second, if it already can appear, isn't that a bug that

On Wed, 10 May 2006, Nick Lewycky wrote: >> Then just run the SCCP pass, and check to see if any operands satisfy >> the predicate "isa<UndefValue>(V)". LLVM explicitly represents >> undefined values. > > I have a case where it doesn't, but perhaps the SCCP pass isn't to blame: > > extern void write_char(int); > > const char foo[4] =

Hello, I am trying to simplify the CFG of a given code and eliminate the conditionals, even though I will obtain codes that are not semantically equivalent. For example, given a simple loop: for(i=0; i<N; i++){    a[i] = i;     if (i%2==0)       a[i] += 12; } I would keep only the loop, without the if statement: for(i=0; i<N; i++){    a[i] = i; } I can eliminate such conditionals on

Chris Lattner wrote: > On Wed, 10 May 2006, Nick Lewycky wrote: > >>> Then just run the SCCP pass, and check to see if any operands satisfy >>> the predicate "isa<UndefValue>(V)". LLVM explicitly represents >>> undefined values. >> >> >> I have a case where it doesn't, but perhaps the SCCP pass isn't to blame: >>