similar to: SCCP is not always correct in presence of undef (+ proposed fix)

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, On Fri, Dec 30, 2016 at 9:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > 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"

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 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 "when, in the intermediate state, can i > >> transform an undef to a different value". > >> > >>

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

Hi Daniel, On Fri, Dec 30, 2016 at 10:55 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> Right, but we are talking about "when, in the intermediate state, can i >> transform an undef to a different value". >> >> Remember you can only go down the lattice. So you can't make undef >> constant, and then discover it's wrong, and go back up :)

> > > > > > You need to distinguish between not visited and visited but undef. > > What I'm getting at is, if you're implementing something close to the > paper mentioned, I can't think of a case where you'd care to > distinguish between "not visited" and "visited but undef". That is, > instead of starting from "map each

> > > Is there a case in your algorithm in which treating an >> unknown as an undef will be a problem? >> >> Yes, if you try to optimize undefs in any way, no if you move them to overdefined :) IE given phi [a, undef, undef, undef] with just as many back edges, you will visit this node 4 times. If you start out with phi [a, undef, undef, undef], you may think

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?

Hi Daniel, On Fri, Dec 30, 2016 at 9:47 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> >>> Is there a case in your algorithm in which treating an >>> unknown as an undef will be a problem? >>> > Yes, if you try to optimize undefs in any way, no if you move them to > overdefined :) > > IE given phi [a, undef, undef, undef] > > with

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

On Fri, Dec 30, 2016 at 10:01 PM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Daniel, > > On Fri, Dec 30, 2016 at 9:47 PM, Daniel Berlin <dberlin at dberlin.org> > wrote: > >> > >>> Is there a case in your algorithm in which treating an > >>> unknown as an undef will be a problem? > >>> > > Yes, if 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

On Fri, Dec 30, 2016 at 10:54 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Fri, Dec 30, 2016 at 10:01 PM, Sanjoy Das <sanjoy at playingwithpointers. > com> wrote: > >> Hi Daniel, >> >> On Fri, Dec 30, 2016 at 9:47 PM, Daniel Berlin <dberlin at dberlin.org> >> wrote: >> >> >> >>> Is there a case in

Hi Félix, Sanjoy Das wrote: > Félix Cloutier via llvm-dev wrote: > > Assuming that this is a bug, what are the next steps? > > Looks like you already have a very small test case -- have you tried > sticking it in a debugger to see why SCCP thinks removing the call is > okay? > > Alternatively, file a bug at llvm.org/bugs and someone will get to it. The third

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