similar to: [LLVMdev] Bugfix: SCCP

On Nov 10, 2009, at 6:58 AM, Stephan Reiter wrote: > 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

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

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

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

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

Hi list, I am making a simple custom pass that inserts print function calls for each instruction, so that compiled programs print out all llvm instructions on the dynamic path. For example, (conceptually) printf(“%s”, “x = x + 1”); // inserted code x = y + 1; // original code But it seems that there are some conflicts with existing optimization paths. When I compile a program with the custom

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

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

Dear LLVM developers, I have a question regarding the IPSCCP class and the handling of dead blocks: The file lib/Transforms/Scalar/SCCP.cpp of llvm 2.8 from contains some code to deal with a dead block which could not be folded (line 1909ff). This happens when a user of this dead block is a branch or switch with an undef condition. The action taken than is to replace this terminator with an

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

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

Devang removed the old llvm/tools/lto directory and renamed lto2 -> lto. The end result of this is that 'svn up' may complain. If you get an error about this from svn, just do: $ rm -rf llvm/tools/lto* $ svn up llvm/tools to fix it, -Chris

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"

I found that llvm-db is the front end for lib/Debugger. I would like to ask you if there is anyone who is actively working on this problem, and if you any specific directions/goals/wish list ~Ioannis On Sep 27, 6:41 pm, Chris Lattner <clatt... at apple.com> wrote: > On Sep 27, 2009, at 3:34 PM, idoud wrote: > > > > > Hi, > > > I would like to ask what is the

I have experienced this with a svn 1.5 client but not with 1.4.6. Did anybody see this with a 1.4.6 (or older) client? Btw. what is the server version? Anyway this seems to be a bug in subversion. Cheers, Gabor PS: http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=79361 On Jul 1, 5:27 am, Chris Lattner <clatt... at apple.com> wrote: > Devang removed the old

No one is working on it or even thinking about it. It is so far from being useful that it should probably just be removed. -Chris On Sep 27, 2009, at 4:29 PM, idoud <doudalis at gmail.com> wrote: > I found that llvm-db is the front end for lib/Debugger. > > I would like to ask you if there is anyone who is actively working on > this problem, > and if you any specific