similar to: [LLVMdev] SCCP

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: >>> 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?

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 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

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

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] =

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: >>

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. I've put together a patch which modifies the behaviour of SCCP so that it preserves undef in those cases. I

Nick Lewycky wrote: > I tested it with "opt -sccp". I should've included a properly runnable > example the first time. Sorry. At least, running "opt -load-vn -gcse" > does not convert foo[0] into "102". Further testing shows that the SCCP optimization will do handle it, and so will the instruction combiner. Chris Lattner wrote: >>I'd suggest

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, 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

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

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?

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

The SCCP pass was failing an assertion that I traced back to SCCPSolver::visitExtractValueInst. getStructValueState was used on the aggregate operand even if it had no structure type. I added a check to use getStructValueState for structs and getValueState for other operands. This behavior was introduced in r85793. Please note that I'm not sure whether my changes correctly address this

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

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

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

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