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 class that is used by the SCCP >>> and IPSCCP classes. You should just be able to use SCCPSolver. Note >>> that it is not a pass, just a class you can use. >> >> >> Thanks. I thought SCCPSolver was just a helper. I suppose then I should >> just move its class declaration into a header so it can be seen from >> outside SCCP.cpp. Would creating a new include/llvm/Transforms/SCCP.h be >> the right idea? > > 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 write an analysis pass that checks the expression at every conditional statement to see whether the value is underdefined or not. This would be after SCCP and other optimizations have already been run, so conditional statements with constant expressions would already be eliminated. (Am I being silly? There isn't a pass to eliminate conditionals on underdefined variables is there?) It would be fine for my purposes to just copy the class declaration into my own code. Nick
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 write an analysis pass that checks the expression at > every conditional statement to see whether the value is underdefined or > not.Then just run the SCCP pass, and check to see if any operands satisfy the predicate "isa<UndefValue>(V)". LLVM explicitly represents undefined values.> This would be after SCCP and other optimizations have already been > run, so conditional statements with constant expressions would already > be eliminated.Right, conditionals like "cst1 < cst2" will certainly be folded to true or false. Also "undef < X" will be folded to undef by the SCCP pass. -Chris -- http://nondot.org/sabre/ http://llvm.org/
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 transformed code? >> >> I was planning to write an analysis pass that checks the expression at >> every conditional statement to see whether the value is underdefined or >> not. > > 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] = "foo"; write_char(foo[0]); write_char(foo[5]); The write_char(foo[0]) correctly becomes write_char('f'), but the write_char(foo[5]) doesn't become undefined, instead staying as a GetElementPtrInst. I thought this might be because the optimizer is being conservative about correctness, but that the lattice must still show it as underdefined -- but obviously as I haven't looked at the lattice directly, I haven't verified that yet. Maybe it becomes overdefined as the constant can't be resolved, and I should just fix the SCCP pass? Nick