Polygon. Entries : Area. Square. Entries : Area

Transcription

1 Global Optimization in YAFL Laurent Ferier March 1996 Abstract This paper describes the means to optimize code generated by a compiler and will focus on optimizations requiring the analysis of an entire program in order to be performed. The optimizations on which this paper will focus are mostly applicable in an object-oriented environment. An optimizer has been implemented to perform some of these optimizations on YAFL programs. 1 Introduction The purpose of a compiler is to translate code written in a language into another whereas the purpose of an optimizer is to detect sub-optimal constructs generated by the compiler and replace them by optimal ones. An optimal construction requires less storage or improves the performances of a system compared to the sub-optimal one. These two kinds of optimization are not always incompatible, but sometimes, a choice has to be done between these two issues. In this case, space will often be sacriced to the benet of time since it is easier to add random access memory in a computer than make it compute faster. Modular languages support the module 1 concept. The specication le of modules provides links between modules of a system. This le holds a partial description of the module. Because of the partition of a system in modules, when the compiler compiles a module, it cannot access the informations of the entire system. Thereby, some sub-optimal constructs might be missed by the compiler. It would need informations about the entire system in order to detect them. For instance, considering the YAFL language [Bla94], let M be a private method dened in a module and never called in the module. Since M is private, M cannot be called outside 1 A module is a compilation unit. It can be compiled independently from the other modules modulo their external specication. 81

2 the module. Thereby, M cannot be called at all and no code has to be generated for M. If M was public instead of being private, M could be called from anywhere in the system. The compiler can only suppress M from the code generated only if no calls to M can be found in the entire system. Global informations are necessary in order to detect it. Meanwhile, such compiler requires much space and time in order to compile the system. A solution could be to use two compilers: A fast one which is used to compile the system during the development phase. The code generated is not the fastest nor the smallest one. A slow compiler which detects most of sub-optimal constructs and generate the most ecient code possible. This compiler needs access to informations about the entire system, and compile time performances is not considered critical. 2 Global optimization in YAFL YAFL is a modular language: the compiler compiles one module at a time. Hence, no global optimization can be performed. The YSTORM optimizer reuses most of the standard YAFL compiler and performs its optimizations using system-wide informations. The global optimization process can be lengthy. However, all eorts have been done to make this process as fast as possible. The implementation part describes these eort (see section 3). The YSTORM optimizer performs most of the optimizations described in this chapter. Those which are not performed are either not the concern of the global optimizer, or would not change signicantly the performances of the code generated. 2.1 Peep-hole Optimizations Peep-hole optimizations are optimizations which only need local and often low-level informations in order to be performed. For instance, these optimizations include dead code suppression, sub-expressions evaluation, etc. Since these optimizations are local, they do not need global informations in order to be performed. Thereby, the global optimizer shall not deal with them. As a matter of fact, the standard YAFL compiler doesn't deal with those optimizations either as long as it is meant to produce intermediate C code, and most C compilers provide such kind of optimizations. 82

3 2.2 Late binding In object oriented languages, the late binding mechanism is used to invoke the right version of a method depending on the object on which the method is being applied to. For instance, consider the example listed extensively in appendix A. Let APolygon be a reference to a Polygon as described in this appendix and consider the call APolygon.; Displayable Move Move Dot Polygon ChangeColor ChangeColor APolygon. Square Figure 1: APolygon. The object referenced by APolygon can be either a Polygon or a Square. Thereby, the call APolygon. can either be applied to the method from Polygon or on the one from Square. The compiler doesn't know at compile-time if the object referenced by APolygon is a Polygon or a Square. It must defer the selection of the right method to run-time. This call is said to require late binding. On the other hand let ADot be a reference to a Dot and consider the call ADot.; 83

4 Displayable Move Move APolygon.ChangeColor Dot Polygon ChangeColor ChangeColor ADot. Square Figure 2: ADot. In this case, the compiler knows that only a Dot can be referenced through ADot because there is no class that inherits from Dot. Thereby, the only method applicable on that call is the method dened in the class Dot. No late binding is needed to perform this call. When the optimizer tries to optimize calls, he will try to nd such calls, and generate code which skips the dynamic selection of the right method to be called. We can also remove late binding for APolygon.ChangeColor(Red); if APolygon a reference to a Polygon, since ChangeColor is not redened. Consider ADisplayable be a reference to a Displayable and the call ADisplayable.; 84

5 Displayable Move Move? ADisplayable. Dot Polygon ChangeColor ChangeColor Square Figure 3: ADisplayable. In a YAFL system, ADisplayable can reference a Square, a Polygon, a Dot or even a Displayable since abstract classes can be CREATEd. Thereby, the compiler cannot determine statically which method is to be applied on the call. It doesn't even know if there is an applicable method ( is DEFERRED in the class Displayable). In this case, the compiler generates a late binding call and if, during run-time, no method is applicable on the call, an error message is displayed and the program stops. The following paragraphs formalize the concepts of late binding and related optimizations Denitions Late binding: When a method is invoked, the late binding mechanism selects the right version of the method to be called, depending on the class of the object it is applied to. Since the selection is performed on objects, not on references, it can only be done during run-time. In order to generate a faster code, the compiler has to remove late binding handling from the generated code as often as possible. This can only be performed when the compiler can make sure there's only one method applicable for the call. 85

6 Class: A class c i is dened by c i =< methods i ; E i ; c j > where M i is the set of the methods dened for c i E i c j is the set of the entry points of c i is c i 's base class The inheritance relationship will be noted (c j! c i ), meaning that c i inherits from c j. S is the set of all classes dened in the system. For instance, in the example given in appendix A, we have S = fc (Displayable) ; c (Dot) ; c (Polygon) ; c (Square) g and (c (Displayable)! c (Dot) ) (c (Displayable)! c (Polygon) ) (c (Polygon)! c (Square) ) Object: An instance of the class c i is called object and is noted o i. The set of all objects of a system is noted O. The set O is dynamic. Derived Classes: Let Dci 1 the set of all classes derived from the class c i. Dci 1 is dened by D 1 ci = fc j 2 Sj(c i! c j )g D l ci is recursively dened by D l ci = Dl?1 ci [ fc j 2 Cj9 c k 2 D l?1 ci and (c k! c j )g For instance, D +c (Displayable) D +c (Dot) D +c (Polygon) D +c (Square) fc (Dot) ; c (Polygon) ; c (Square) g fg fc (Square) g fg 86

7 Entry Point: An entry point e j is the denition of an operation applicable on instances of one or more classes from S. The entries dened in the system from appendix A are e (), e (), e (Move), e (ChangeColor) and e (). Method: A method m ij of a class c i is an operation applicable on an instance of the class c i. It is dened by where m ij =< e j ; Iij > e j is the entry attached to m ij Iij are the statements of m ij The set of all methods of a system is noted M. The following table displays methods according to the example listed in appendix A and their corresponding class. Class c (Displayable) c (Dot) Method m (Displayable, Move) m (Dot, ) m (Dot, ) m (Dot, ChangeColor) c (Polygon) m (Polygon, ) m (Polygon, ) m (Polygon, ) c (Square) m (Square, ) Call: A Call a ij is the invocation of an entry point e j on an object from the class c i or one of its derived class. Only methods which corresponding entry is e j may be called through a a ij. The set of all calls of a system is noted A. 2.3 Late binding problem in C++ In order to reduce the loss of performances due to late binding, C++ allows the programmer to specify which functions are to be invoked through late binding. Those functions are called virtual functions. 87

8 This approach simplies compiler design since no analysis is required to determine if a method invocation has to be done through late binding. No other functions than those explicitly marked as virtual are to be called through late binding. However, this approach does have drawbacks. First, the programmer has to determine himself (herself) which methods are virtual, which is not always a simple choice. Furthermore, since a non virtual method cannot be redened, the programmer has to know how the classes are to be used before committing. One can see that code reusability in a C++ environment is rather painful, unless all functions are marked as virtual, hence a signicant performance penalty. Even if only potentially redened methods are marked as virtual, some optimizable calls may still be forgotten. Consider for instance the following C++ code: class AClassf... virtual void Func1(); g; class BClass:public AClassf... void Func1(); g;... BClass *TheBClass; TheBClass->Func1();... Since Func1() is redened, it must be declared as virtual. Thereby, each time a call is done to Func1, the C++ compiler has to generate a late binding call. In a system where no class inherits from BClass, the function Func1 cannot be further redened. Thereby, there's only one applicable function on the call TheBClass->Func1(). The compiler should be able to determine statically which method has to be called and no late binding is necessary. By this example, one can see late binding is more linked to the function call than to the function itself. The C++ model is sub-optimal since a large property of monomorphic function calls still require late binding in order to be performed. 2.4 Some more denitions Applicable methods on a method call: Since methods can be redened, several methods may be invoked on the same method call, depending on the actual class of the object 88

9 the method is being applied for. When a call is performed, the method applied is the rst method the compiler nds going up in the inheritance tree from the class of the object on which the call is applied. Let F irst ij () be the rst method in the inheritance tree restricted to the set of classes of and matching the call a ij. F irst ij () is dened by where F irst ij () = m kj c i 2 (D ck \ ) 6 9 m lj jc l 2 (D + ck n D ci ) Let V ij () be the set of all methods which could be executed on a call a ij classes from the set. V ij () is dened by considering all V ij () can also be dened by V ij () = fm kj j m kj = F irst kj () and c k 2 g V ij () = fm kj j c k 2 D + ci \ g [ ff irst ij()g (1) Taking the example in appendix A, we have and F irst (Displayable, ) (S) = V (Displayable,) (S) = fm (Dot, ) ; m (Polygon, ) ; m (Square, ) g Figure 4 illustrates this example. F irst (Square, Move) (S) = m (Displayable, Move) V (Square, Move) (S) = fm (Displayable, Move) g 89

10 Displayable First (Displayable, ) Move Move? Dot Polygon ChangeColor ChangeColor Square First (Square, Move) Figure 4: Example of computation of F irst() Monomorphic call: Polymorphic call: Wrong call: A call a ij is monomorphic, only one method is applicable, jv ij (S)j = 1 A call a ij is polymorphic, more than one methods is applicable, jv ij (S)j > 1 A call a ij is wrong, no method is applicable, jv ij (S)j = 0 90

11 Selection function: The general case for the selection function is dened by where Sel : A O! M : a ij o k 7! m lj m lj 2 V ij () Sel is the function which selects which method has to be applied on an object at run-time. denes the classes to be accounted for. In a strong typing environment, we have c k 2 D ci The method is selected as follows: Sel(a ij ; o k ) = ( F irst ik (S) if V ij (S) 6= otherwise When Sel() is applied on objects during run-time, F irst ij () is used during compilation to compute V ij (). Trivial cases: The selection function Sel(a ij ; o k ) is trivial in two cases: V ij (S) =. The compiler should raise an error since it knows no method is applicable on the call a ij. Nevertheless, we choose to emit a warning instead of refusing such a call since the call may not be performed. This can happen even if the statement where the wrong call stands is executed. Consider the following example: IF TRUE OR ABadCall THEN Since the rst part of the condition is always true and thanks to lazy evaluation, the compiler just skips the call a (ABadCall). V ij (S) = fm kj g. Since the selection function takes its values in V ij (), we have 8l Sel(a ij ; o l ) = fm kj g The compiler knows at compile-time which method is to be invoked for that specic call. Thereby, late binding is not required. If V ij (S) is not known, the call has to be done through late binding because the compiler doesn't know the value of Sel(a ij ; o k ) or even if a value exists. 91

12 2.5 Computing V ij (S) in YAFL In order to avoid the problems described in 2.3 for C++, all YAFL non local methods can be redened. Thereby, if the code generated by the standard YAFL compiler was not optimized, all method invocations would have been done through late binding. Fortunately, the compiler can detect some static calls 2 and optimize them. The purpose of the global optimizer is to nd more static calls than those found by the compiler, but basically, the underlying principles are the same Calls to local methods Local methods are methods dened within another method. Since these methods cannot be redened, jv ij (S)j = 1 for any call a ij to such method. The compiler does not have to generate any late binding call applied onto local methods. Since no global information is required to compute V ij (S), the standard YAFL compiler already optimizes method calls applying to these methods Calls to methods applied to ONCE classes ONCE classes are classes for which only one instance exists, which is created by the system at initialization time. No class may inherit from ONCE classes. Consider a ONCE class c i, and a method m ij dened or redened in c i. We know (see (1)) V ij (S) = fm kj j c k 2 D + \ Sg [ ci ff irst ij(s)g Since no class inherits from c i, D + ci =. m ij is (re)dened in c i, hence F irst ij (S) = m ij. The compiler knows which method is invoked by a ij. A straight call to m ij may be performed. No global information is necessary in order to detect ONCE classes. Hence the standard YAFL compiler already optimizes such calls Calls to private methods Private methods are methods only usable in the module in which they have been dened. Since those methods can only be redened in the same module, the set on which V ij () can be limited to classes dened in the current module. Thereby, the standard YAFL compiler can determine V ij (). It can then determine whether late binding is necessary. Once again, since only informations about the current module are necessary to compute V ij (), the standard YAFL compiler already optimize such calls. 2 Opposing to late binding calls. Static calls are also called monomorphic calls. 92

13 2.5.4 Calls to public methods Public methods are methods which are visible from outside their enclosing module. Since these methods can be redened in other modules if their enclosing class is not ONCE, we can have where V ij (S) n V ij () 6= = fc i jc i is dened in the current module g Thereby, system-wide informations are necessary to nd out optimizable calls to public methods. Thereby, the standard YAFLcompiler cannot optimize such calls. A global optimization is the only mean to optimize them. 2.6 Extensions of the selection function The selection function may be extended for several parameters, others than the object on which the method is applied. For instance, SmallTalk[GR83] is a language where no information about static type of an object is provided. An object is supposed to accept any message 3 and the validity of the message is tested at run-time. If the message is not a valid one, an error message is sent. The SmallTalk compiler cannot determine V ij (S) for a message since the class c i on which the message is sent is not known. Nevertheless, in order to perform optimizations, the compiler does some duplicate code. Code duplication: Code duplication is the generation of the same piece of code, each one optimized for a given context of execution. In order to replace polymorphic messages passing by monomorphic ones, some SmallTalk and SmallTalk-like systems[cha92] duplicate methods, each one optimized for the actual classes of its parameters. The denition of a method is slightly modied: m [i1 ;:::;in];j =< e j ; Ifi 1 ; : : : ; i n g > The method m [i i;:::;in];j is applicable only on objects from dynamic class c i1 and which parameters are respectively from the classes c i2 ; : : : ; c i n. The selection function is dened by: Sel : A (O) n! M : a i o i1 o i n 7! m [i1 ;:::;in];j 3 A message is the SmallTalk's word for YAFL's method call 93

14 where o i1 o i2 : : : o i n is the object on which the method is applied are the objects given as parameters In such a context, the compiler knows the dynamic type of the parameters. The selection function is then no more useful for message passing on parameters since the dynamic type is known during compilation 4. Thereby, messages on parameters in optimized method can be performed straight. Thanks to code duplication, the selection is done only once, during message passing. The selection is performed only once and as early as possible. A compiler cannot generate all versions of the method, each one optimized for a dierent set of parameters. Thereby, this optimization is mainly used in systems providing run-time compilation features. If a message is passed to a class where the method has not yet been compiled, the compiler generates, stores it and executes it on the y. 2.7 Inlining Inlining replaces calls to functions by the actual body of the function. This is mainly used to minimize time lost during function call. One must weight carefully what should be inlined in order to keep the code reasonably small Inlining in C++ C++ allows the programmer to dene functions as requiring inline extension. Such functions cannot be redened. Thereby, when the programmer has dened a non virtual function, he has to nd out if the method is worth to be inlined or not. One of the advantages of the C++ technique, beyond the fact that it simplies code generation, is that there is no restricting pattern for inline function. Therefore, any function may be extended inline if the programmer choose so. C++ consider inline only as a compilation directives which can be forgotten if the compiler whishes Inlining in YAFL YAFLdoes not dene any syntaxical constuct to dene inlinable methods. Since YAFLprovides encapsulation, the only mean to access attribute is methods. Thereby, most classes denes methods to either read or modify the value of its attributes. We will 4 That's the reason why the compiler duplicated the methods 94

15 call such methods attribute accessing methods. These are used a lot in YAFLsystems and rather trivial to inline. So, we decided to inline them. Inlining a method invocation requires the invocation to be monomorphic. Since the standard YAFL compiler cannot determine much monomorphic calls, it could not inline much method calls. On the other hand, the global optimizer detects all monomorphic calls of a system. Thereby, inlining is possible and interresting. It uses a simple pattern matching to detect attribute accessing methods. The simple preceding scheme, presented above can actually be extended to handle cases when a chain of method invocation can be replaced by a chain of attribute consultation. 2.8 Removing unreachable code When one writes and tests a program, he (she) normally inserts debugging statements, which are removed when the system goes to production. YAFL denes DEBUG and ASSERT statements which serve this purpose. Any optimizer can walk through the code and remove such statements. No global optimization is necessary. On the other hand, when using class libraries within a system, some methods are never invoked at all. No code generation is necessary for such methods. A class is useless if no instance of that class is ever CREATEd explicitly. Reachable call: Let A M be the set of all reachable calls from the set M. a ij 2 A M, 9 m kl 2 M and a ij 2 I kl Reachable method: Let M M be the set of all reachable methods from the set M. m ij 2 M M, 9 a kj 2 A M and m ij 2 V kj (S) Reachable class: Let C M be the set of all reachable methods from the set M. c i 2 C M, 9 m ij 2 M M The detection of unreachable classes and methods is performed as follows: S While all classes S is not of the stabilized systemdo M fm (i, CREATE) j c i 2 S is ONCE or the entry classg While M i s not stabilized do M End while S C M End while M [ M M 95

16 At the end of the algorithm, S is purged from all unused classes and M is the set of all methods which can possibly be used. Since V ij (S) is needed for this optimization, this optimization requires global informations in order to be performed. 3 Implementation and Performances 3.1 First Optimizer Since the global optimizer needs informations about the entire system, it seemed reasonable to load and analyze the entire system in one time. This approach led us in rather awful problems of memory management and performances. Since large amounts of memory were allocated, most pages of the process were swapped out. When launched, the garbage collector, which is not a local process, used most of its time to swap pages in and out. 3.2 An usable optimizer Since only a few of global informations are required for our optimizations (the inheritance tree, classes, methods, entry points, calls performed by a method, : : : ), only a subset of the system must be kept accessible during the entire process. We introduced dictionaries which purpose is to keep such information and to infer on them. The optimization process is divided in three phases: Analyzing the entire system and storing information in dictionaries. Inferring on these informations, as computing V ij (S), determining which calls are monomorphic, : : : Reloading each module one after the other and generating code using possible optimizations as described in preceding chapter and global informations gathered in the preceding steps. This approach allows us to spare much space and to have compile-times about two or three times longer than a normal compilation. It has been merged with the standard YAFL compiler and can be activated when needed. In the meantime, dictionaries are used in other projects to gather information about YAFL systems. 96

17 4 Conclusions Some results: Time consumption Superuous late binding to public methods 30% Unavoidable late binding 3% Monomorphic access to attributes 10% Garbage collection 15% Application 42% Total 100% Only 90% of the method invocations were monomorphic. Thereby, real polymorphic calls take about 3% of the run-time for a YAFL system. which is rather cheap for the facilities object oriented languages provide. Even if superuous late binding was not removed, the cost of object orientation would not be as heavy as people often expect. References [Bla94] Darius Blasband. The YAFL Programming Language, 2nd edition. PhiDaNi Software, [Cha92] Craig Chambers. The Design and Implementation of the SELF Compiler, an Optimizing Compiler for Object-Oriented Programming Languages. PhD thesis, Stanford University, March Available via anonymous ftp from self.stanford.edu. [GR83] A. Goldberg and D. Robson. Smalltalk-80: The Language and Its Implementation. Addison-Wesley, Reading, Mass., A An example In order to be more understandable, here follows a YAFL example, which will be used throughout this paper. DEFINITION MODULE Polygons; FROM List IMPORT List; 97

18 CLASS Displayable; REDEFINE METHOD CREATE (PosX, PosY : INTEGER); DEFERRED METHOD ; DEFERRED METHOD ; METHOD Move (dx, dy : INTEGER); END Displayable; CLASS Dot; INHERITS Displayable; REDEFINE METHOD CREATE(PosX, PosY, Color : INTEGER); METHOD ChangeColor (NewColor :INTEGER); END Dot; CLASS Polygon; INHERITS Displayable; REDEFINE METHOD CREATE (PosX, PosY : INTEGER; Vertexes : List(Dot); Color : INTEGER); METHOD ChangeColor (NewColor :INTEGER); METHOD : REAL; END Polygon; CLASS Square; INHERITS Polygon; REDEFINE METHOD CREATE (PosX, PosY : INTEGER; Vertexes : List(Dot); Color : INTEGER); END Square; END Polygons; IMPLEMENTATION MODULE Polygons; CLASS Displayable; VAR X, Y : INTEGER; REDEFINE METHOD CREATE (PosX, PosY : INTEGER); X := PosX; Y := PosY; END CREATE; METHOD Move (dx, dy : INTEGER); ; X := X + dx; Y := Y + dy; 98

19 ; END Move; END Displayable; CLASS Dot; INHERITS Displayable; VAR Color, Back : INTEGER; REDEFINE METHOD CREATE(PosX, PosY, Color : INTEGER); BASE (PosX, PosY); THIS.Color := Color; END CREATE; REDEFINE METHOD ; Back := Back of the dot -- the dot... END ; REDEFINE METHOD ; -- the back of the dot... END ; METHOD ChangeColor (NewColor ; Color := NewColor; ; END ChangeColor :INTEGER); END Dot; CLASS Polygon; INHERITS Displayable; VAR Vertexes : List(Dot); Color : INTEGER; 99

20 Back :... ; : REAL; REDEFINE METHOD CREATE (PosX, PosY : INTEGER; Vertexes : List(Dot); Color : INTEGER); BASE (PosX, PosY); THIS.Vertexes := Vertexes.CLONE; THIS.Color := Color; THIS. :=... ; END CREATE; REDEFINE METHOD ; -- the polygon END ; REDEFINE METHOD ; -- the polygon END ; METHOD ChangeColor (NewColor ; Color := NewColor; ; END ChangeColor; :INTEGER); METHOD : REAL; RESULT := THIS.; END ; END Polygon; CLASS Square; INHERITS Polygon; REDEFINE METHOD CREATE (PosX, PosY Vertexes Color : INTEGER; : List(Dot); : INTEGER); 100

21 ASSERT Vertexes.Size = 3; BASE (PosX, PosY, Vertexes, Color); END CREATE; REDEFINE METHOD ; -- Optimized method show for squares END ; REDEFINE METHOD ; -- Optimized method show for squares END ; REDEFINE METHOD ; -- Optimized method show for squares END ; END Square; END Polygons; This module could be used to display several geometric gures. Each gure given here can be CREATEd, Hidden, n, Moved and one can change their color. 101