03.10.2012, 21:49, "Yang Chen" <[email protected]>:
> On 10/3/12 2:53 AM, Konstantin Tokarev wrote:
>
>> Hi all,
>>
>> What values of "pri", "first_pass_pri", "last_pass_pri" mean?
>
> These numbers means the priorities of passes. Here is how creduce
> invokes these passes:
> - first runs passes which have "first_pass_pri" values;
>
> - then enters the main delta loop, where passes with "pri" values are
> invoked in the ascending order of those values. At the beginning of each
> iteration of the main loop, creduce records the size the code under
> reduction, e.g., size_a. After all "pri" passes are exercised, creduce
> compares the size of the reduced code (e.g., size_b) with size_a. If
> size_b is less than size_a, creduce will do another iteration, i.e.,
> runs all "pri" passes; otherwise, we exists the main delta loop and get
> to the last phase. In other words, the main delta loop keeps doing
> reduction until reaching a fixpoint. Here the fixpoint is the code size.
>
> - passes with "last_pass_pri" values run only in the last phase.
> These passes do some cleaning work, e.g., renaming function, renaming
> variables, etc.
>
> For example, let's say we have the following passes:
> A1{first_pass_pri = 1} , A2 {first_pass_pri = 2}, A3 {first_pass_pri
> = 3}
> B1 {pri = 1}, B2 {pri = 2}, B3 {pri = 3}
> C1 {last_pass_pri = 1}, C2 {last_pri = 2}
>
> Then the passes will be executed like the following order:
>
> first phase: A1 -> A2 -> A3
> main loop:
> iteration 1: B1 -> B2 ->B3 (size comparison, succeeded)
> iteration 2: B1 -> B2 -> B3 (size comparison, succeeded)
> iteration 3: B1 -> B2 -> B3 (size comparison, reaching fixpoint, and
> leaving from the main loop)
> last phase: C1 -> C2
>
> All done.
>
So there's no parameter which affects exit from pass, is there?
Sometimes some pass becomes ineffective and preliminary break could be helpful,
>> If I have passes A and B, how do I make creduce run them in order A, B, A?
>
> If A and B *only* belong to "pri" passes, then you cannot have an order
> such as "A, B, A", rather you will have "A, B, A, B". But alternatively,
> we could have "A, B, A" order by doing something like:
> A {first_pass_pri = 1, pri = 1}
> B {pri = 2}
>
> Then you will end up with "A, A, B, A, B...". But I guess this might not
> be what you want...
There are passes which remove unused template parameters:
* reduce-class-template-param ("pri" => 230)
* class-template-to-class ("pri" => 232)
I'm writing new pass substitute-class-template-param, which will substitute
template parameter to some type or value, if it is the same in all
instantiations,
e.g.
template<typename T>
class B {
T t;
};
will become
template<typename T>
class B {
int t;
};
if only B<int> is instantiated. At first I thought my pass will rewrite it to
class B {
int t;
};
but then decided it would be wiser to leverage existing passes
reduce-class-template-param and class-template-to-class and make
things simple.
IMO, optimal order inside delta loop should be
... // passes
{
reduce-class-template-param
remove-trivial-base-template
class-template-to-class
} // this is A
substitute-class-template-param // this is B
//A again
... // other passes
i.e. (..., A, B, A, ...) inside each loop. Any ideas?
--
Regards,
Konstantin
