Hi, guys,<br><br>    thank you for all the feedback. I will try to answer your<br>questions below. But, if you think that might not be a good GSoC<br>project, do not hesitate to tell me. I can try to write a different<br>proposal. Nevertheless, I would like to hear from you what you think<br>

is important to have in the range analysis. By reading your e-mails, I<br>see that there are still a lot of things that we do not do, and would<br>be useful to the community:<br><br>> can you speed up program runtime significantly using this analysis?<br>

<br>No, not yet. We have not used the analysis to implement any<br>optimization yet. So far we can only flag that variables are<br>dead-code, but I have not tried to remove this code. And for the C<br>programs that we have analyzed, the number of variables that are<br>

dead-code, after LLVM optimizes the program, is small. We found<br>something like 200 dead variables in the whole gcc, for instance.<br>Notice, however, that the other optimizations had not caught those.<br><br>> I took a brief look at your report.  I'm not sure what others in the<br>

> LLVM community think (and I'd like their input), but I suspect that<br>> 10-15 seconds for analyzing GCC means that users would want your<br>> analysis enabled at optimization levels higher than -O2.<br><br>

It is a whole (inter-procedural) program analysis, with function<br>inlining enabled to give us a limited form of context-sensitiveness.<br>If I run it intra-procedurally, it takes negligible time per function.<br>I think its runtime is similar to other LLVM passes.<br>

<br>> When I asked for memory usage, I meant the amount of RAM used by the<br>> analysis.  As far as I can tell, your paper only reports the number of<br>> constraints, so it doesn't really tell me how much RAM the analysis<br>

> uses.<br><br>I just measured it. For SPEC 2006 gcc it took 455MB.<br><br>> One other thing I've been wondering about is whether your analysis is<br>> able to find value ranges for the results of load instructions.<br>

<br>No. We do not do not use pointer analysis.<br><br>> Finally, do you think it would be possible in the future to use<br>> parallelism to improve the performance of your analysis?<br><br>We did not think about it. I think that the algorithm, in the way it<br>

is now, is pretty sequential. We can parallelize the processing of<br>strong components that do not depend on each other, but I speculate<br>that there are not many of these.<br><br>> I recommend that your proposal mention that you'll try your analysis on<br>

> larger and more diverse codes<br><br>Yes, we want to find larger benchmarks too.<br><br>> one of the big problems with Douglas's original range analysis was that<br>> it couldn't handle modulo arithmetic.<br>

<br>We still have this problem. Jorge Navas, who is using our analysis, is<br>working on an implementation that deals with wrapping arithmetics, but<br>we did not have access to his code yet.<br><br>> An analysis that is not sound with respect to the original C/C++ semantics<br>

> would be of little use to anyone.<br><br>You can use our analysis to remove overflows. If we output that a variable<br>is bound to the range [c1, c2], where c1 > -inf, and c2 < +inf, then you<br>are guaranteed to be inside these bounds. The imprecision happens when<br>

we output that something is bound to, say, [c1, +inf], c1 > -inf, because,<br>in this case, you could have that the upper bound of the variable<br>wraps around, and then you may have it changing the lower limit c1. In<br>

our experiments, about 75% of the non-trivial limits that we output is<br>[c1, c2], c1 > -inf, and c2 < +inf, and could be used to eliminate<br>overflow tests. For instance, in gcc we output 40,043 good limits, 22,369<br>

limits [c, +inf], 785 limits [-inf, c], and 116,637 limits [-inf, +inf].<br><br>> Also, the tricky bit of range analysis is handling loops.  I suggested<br>> to Douglas that he exploit LLVM's SCEV infrastructure to discover and<br>

> exploit how induction variables are evolving rather than trying to<br>> create his own poor man's version using interval arithmetic.  How are<br>> loops handled now?<br><br>Yes, Douglas told me about this. He actually wrote a small pass that<br>

catches induction variables using SCEV. We still catch tighter<br>intervals with our range analysis than using SCEV, but we miss some<br>induction variables that SCEV handles. Integrating SCEV into our<br>analysis is in the high list of priorities.<br>

<br>