Difference: CS255Spring09Discussions (4 vs. 5)

Revision 52009-02-23 - JohnPershing

Line: 1 to 1
 
META TOPICPARENT name="CS255Spring09"

CS255/455 Spring 2009 Discussion Board

Last year's discussion page was a success for people to discuss and share the project experience, especially their experience with GCC. So this year, we are going to continue with the discussion tradition. This page is intended for anyone to post questions and everyone to answer them. Please insert questions at the beginning and separate each question with a horizontal rule separator. For other formatting instructions read the answer to this question.


Changed:
<
<
Q: I had several questions that Bin answered via e-mail. He asked me to summarize them here. It was never really detailed in class exactly what you do when you find a redundant statement. My initial thought was to simply replace the right hand side of a redundant statement with the left hand side of the statement which it was repeating. I then noticed that the success benchmark in this class how many statements we could remove from a program, and this method didn't remove any, it optimized the program by decreasing the number of operations executed, but didn't change the statement count. My next thought was that you needed to delete the statement and replace subsequent instances of the left hand side with what you would have replaced the right hand side with, but that has issues since we're only doing local value numbering, and deleting a statement could have wide spread effects in other basic blocks. So the question is what action should we take when we find a redundant statement?
>
>
Q: How do you convert an int back into an INTEGER_CST? I couldn't find any reference in the documentation.

A: Try build_int_cst, which is in tree.c


Q: I had several questions that Bin answered via e-mail. He asked me to summarize them here. It was never really detailed in class exactly what you do when you find a redundant statement. My initial thought was to simply replace the right hand side of a redundant statement with the left hand side of the statement which it was repeating. I then noticed that the success benchmark in this class how many statements we could remove from a program, and this method didn't remove any, it optimized the program by decreasing the number of operations executed, but didn't change the statement count. My next thought was that you needed to delete the statement and replace subsequent instances of the left hand side with what you would have replaced the right hand side with, but that has issues since we're only doing local value numbering, and deleting a statement could have wide spread effects in other basic blocks. So the question is what action should we take when we find a redundant statement?
  A: This question reveals a very important issue in compiler design, interaction among various compiler optimizations. It is true that we can not simply remove a redundant assignment during value numbering. But the later dead code elimination phase should be able to handle this properly. Here is an example to illustrate this.
Line: 13 to 18
 d = b + c; e = b + d; f = b + a;
Changed:
<
<
should be transformed (by LVN) into
>
>
should be transformed (by LVN) into
 a = b + c; d = a; e = b + a; // here d get replaced with a. f = e;
Changed:
<
<
We also replaced d in e = b + d here, because that can eliminate a use to d. Then if there is no use to d after d = a, dead code elimination can remove d = a. However, in a real compiler, such a replacement is not always beneficial, because it will increase the lifetime of variable a, which might cause trouble to later register allocation phase. Again, here you can see the interaction among optimization phases. For our project, the metric of your compiler performance is the number of executed statements, so you don't need to worry about register allocation here.
>
>
We also replaced d in e = b + d here, because that can eliminate a use to d. Then if there is no use to d after d = a, dead code elimination can remove d = a. However, in a real compiler, such a replacement is not always beneficial, because it will increase the lifetime of variable a, which might cause trouble to later register allocation phase. Again, here you can see the interaction among optimization phases. For our project, the metric of your compiler performance is the number of executed statements, so you don't need to worry about register allocation here.
 
URCC problems
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback