Patent Application
20240020101
This application claims priority to Indian patent application number 202041054066, filed on 11 Dec. 2020.
The disclosure generally relates to compiler infrastructures in computer systems and, in particular, to a system and method for performing self-stabilizing compilation.
Mainstream compilers perform multitude of optimization passes on a given input program. Optimization may refer to transformation of computer programs to provide advantages like increased execution speed, reduced program size, reduced power consumption, enhanced security, reduced space utilization, and so on. Typically, an optimization may involve multiple alternating phases of inspections and transformations. In the inspection phase, various program-abstractions, such as intermediate representation (IR) of programs, results of program analysis, etc., may be read to discover opportunities of optimizing the program. Subsequently, the program is transformed in the transformation phase by invoking appropriate writers on the intermediate representations of the program, such as abstract syntax tree (AST), three-address codes, etc.
Upon transformation of a program, the program abstractions, such as points-to graph, constant maps, and so on, generated by various analysis may be inconsistent with the modified state of the program. This prevents correct application of the downstream transformations until the relevant abstractions are stabilized, either via incremental update, or via invalidation and complete recalculation. Thus, unless explicit steps are taken to ensure that the program-abstractions always reflect the correct state of the program at the time of being accessed, the correctness of the inspection phase(s) of the downstream optimizations cannot be ensured, which in turn can negatively impact the optimality, and even the correctness of the optimization.
In general, the existing compiler frameworks do not perform automated stabilization of such abstractions. As a result, the optimization writer have the additional burden to identify (i) what data structures associated with program-abstractions to stabilize, (ii) where to stabilize the data structures, and (iii) how to perform the actual stabilization. Further, adding new analysis becomes a challenge as existing optimizations may impact it. Moreover, the challenges become much more difficult in the case of compilers for parallel languages, where transformations done in one part of the code may warrant stabilization of program-abstractions of some seemingly unconnected part, due to concurrency relations between both the parts.
There have been various attempts towards enabling automated stabilization of specific program-abstractions, in response to program transformations in compilers of serial programs. However, these efforts involve different drawbacks. For example, Carle and Pollock [1989], and Reps et al. [1983] require that the program-abstractions have to be expressed as context dependent attributes of the language constructs, which is very restrictive. Carroll and Polychronopoulos [2003] do not handle pass dependencies and compilers of parallel programs. Blume et al. [1995], Brewster and Abdelrahman [2001] handle only a small set of program-abstractions, and hence insufficient.
Further, there are also some publications relating to incremental update of data-flow analysis. Arzt and Bodden [2014] have provided approaches to enable incremental update for IDE-/IFDS-based data-flow analyses. Ryder [1983] discusses two powerful incremental update algorithms for forward and backward data-flow problems, based on Allen/Cocke interval analysis [Allen and Cocke 1976]. Sreedhar et al. [1996] disclose methods to perform incremental update for elimination-based data-flow analyses. Some important approaches have been given by Carroll and Ryder [1987, 1988] for incremental update of data-flow problems based on interval, and elimination-based analyses. Owing to the presence of inter-task edges (or communication edges) in parallel programs, such as OpenMP programs, there are a large number of improper regions (irreducible subgraphs) in the control and data flow representations of such programs, rendering any form of structural data-flow analyses infeasible over the graph [Muchnick 1998]. Other publications include works by Marlowe and Ryder [1989] and from the two-phase incremental update algorithms for iterative versions of data-flow analysis given by Pollock and Soffa [1989]. However, the pass writer needs to provide additional information to ensure incremental update of their data-flow analyses in these publications.
Given the importance of data-flow analyses, there have been numerous publications that have provided analysis-specific methods for incremental update, as well as its parallelism. For instance, in the context of C programs, Yur et al. [1997 ] have provided incremental update mechanisms for side-effect analysis. Chen et al. [2015] have provided incremental update of inclusion-based points-to analysis for Java programs. Similarly, Liu et al. [2019] have provided an incremental and parallel version of pointer analysis. However, these and other publications are not generic in nature. Therefore, there are no compiler designs or implementations that address the challenges discussed above and guarantee generic self-stabilization, especially in the context of parallel programs. In contrast, the disclosed method completely hides the implementation of parallelism semantics, and incremental modes of self-stabilization, from the writers of existing and future iterative data-flow analyses (IDFAs).
A computer-implemented method for automatic self-stabilizing compilation of programs is disclosed. The method includes receiving an input program. A plurality of abstractions of the input program are generated using a plurality of analysis operations, wherein each one of the plurality of abstractions represents information associated with a program state at compile time. Next, the method includes performing one or more optimization operations on one of the plurality of abstractions expressed in terms of one or more predetermined elementary transformations. The predetermined elementary transformations capture the information associated with the modified program state. One or more of the plurality of abstractions are stabilized by a stabilizer using the information captured by the set of predetermined elementary transformations in a stabilization mode. The stabilizing includes updating the one or more abstractions using the captured information to maintain consistency of the abstractions with the modified program states.
In various embodiments, the predetermined elementary transformations include adding, deleting, or modifying syntactic parts of the program. In some embodiments, the stabilization mode is one of a lazy-invalidate stabilization mode, lazy-update stabilization mode, eager-update stabilization mode, eager-invalidate stabilization mode, or any combination thereof. In various embodiments, the one or more abstractions represent information associated with a serial or parallel program. In some embodiments, the plurality of abstractions include intermediate representation, a control flow graph, and an abstract syntax tree. In some embodiments, the plurality of abstraction includes iterative data flow analyses, and wherein the iterative data flow analyses are stabilized using automatic lazy-update stabilization mode. In some embodiments, the method includes stabilizing the one or more abstractions in response to performing new optimization operation, wherein the stabilizing comprises updating the one or more abstractions to maintain consistency of the abstractions with the modified program states.
According to another embodiment, a system for performing automatic self-stabilizing compilation of programs is disclosed. The system includes an analysis component configured to receive an input program and perform a plurality of analysis operations of the input program to generate a plurality of abstractions, wherein each one of the plurality of abstractions represents information associated with a program state at compile time. The system includes an optimization component configured to perform one or more optimization operations on one of the plurality of abstractions by modifying the program state associated with the abstraction based on a set of predetermined elementary transformations, which capture the information associated with the modified program state. The system also includes a stabilizer configured to stabilize one or more of the plurality of abstractions using the information captured by the set of predetermined elementary transformations, wherein the stabilizing includes updating the one or more abstractions using the captured information to maintain consistency of the abstractions with the modified program states.
In various embodiments, the analysis component includes pre-processing unit, lexical analysis unit, syntax analysis unit, and semantic analysis unit. In some embodiments, the stabilizer is configured to operate in a stabilization mode, wherein the stabilization mode is one of lazy-invalidate stabilization mode, lazy-update stabilization mode, eager-update stabilization mode, eager-invalidate stabilization mode, or any combination thereof. In some embodiments, the optimization component includes one or more abstraction readers and one or more abstraction writers. The one or more abstraction readers are configured to read the one or more abstractions and the one or more abstraction writers are configured to modify the one or more abstractions.
This and other aspects are described herein.
The invention has other advantages and features, which will be more readily apparent from the following detailed description of the invention and the appended claims, when taken in conjunction with the accompanying drawings, in which:
While the invention has been disclosed with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt to a particular situation or material to the teachings of the invention without departing from its scope.
Throughout the specification and claims, the following terms take the meanings explicitly associated herein unless the context clearly dictates otherwise. The meaning of “a”, “an”, and “the” include plural references. The meaning of “in” includes “in” and “on.” Referring to the drawings, like numbers indicate like parts throughout the views. Additionally, a reference to the singular includes a reference to the plural unless otherwise stated or inconsistent with the disclosure herein.
The present subject matter describes methods and systems for self-stabilizing compilation of computer programs for serial and parallel programming applications. According to the present subject matter, self-stabilizing compilation relates to updating of the internal program-analyses-related information within a compiler, in response to program changes due to different optimizations within the compiler.
A flow diagram for a method for automatic self-stabilizing compilation of programs is illustrated in
Next, a series of optimization operations may be performed on one of the plurality of abstractions by modifying the program state associated with the abstraction based on a set of predetermined elementary transformations at block 106. The optimization operation may be performed using the information present in one or more of the plurality of abstractions. In various embodiments, the optimization operation may include inspection and transformation of the abstractions. Each transformation may involve modification of the program or abstraction state. In various embodiments, the predetermined elementary transformations may include adding, deleting, or modifying syntactic parts of the input program.
One or more of the plurality of abstractions may be stabilized using the information captured by the set of predetermined elementary transformations in a stabilization mode at block 108. The stabilizing may include updating the one or more abstractions to maintain consistency of the abstractions with the modified program states. In various embodiments, the steps 104, 106, and 108 may be performed multiple times during the compilation of the received input program. In some embodiments, the stabilization mode is one of a lazy-invalidate stabilization mode, eager-update stabilization mode, eager-invalidate stabilization mode, and an lazy-update stabilization mode. In various embodiments, the method may include stabilizing one or more abstractions of parallel programs. In various embodiments, the method may further include automatically stabilizing the one or more abstractions in response to adding new optimization by updating the one or more abstractions to maintain consistency of the abstractions with the modified program states.
A block diagram of a system 200 for performing automatic self-stabilizing compilation of programs is illustrated in
A block diagram of the compilation process is illustrated in
The pre-processing unit 304 may be configured to expand various macros and header files in the input program. The lexical analysis unit 306 may be configured to break the source code text into a sequence of small pieces called lexical tokens, such as keywords, operators, literals, identifiers, and the like. The syntax analysis unit 308 may also be configured to identify syntactic structure in the input program by parsing the token sequence. In some embodiments, the syntax analysis may generate an abstraction 316 such as a parse tree, which represents the program in a tree structure.
The semantic analysis unit 310 may be configured to generate a new abstraction or modify the existing abstractions 316 by performing operations like type checking, object binding, rejecting incorrect programs or issuing warnings. The code optimization unit 312 may be configured to perform machine dependent and machine independent optimizations of the program. The transformed program may be translated by the code generation unit 314 into an output language, such as assembly language, bytecode, or machine code.
A block diagram of the self-stabilization compilation is illustrated in
Abstraction readers 402 (or intermediate representation readers) may be configured to read the one or more abstractions 316 into the memory, such as hard disk or the random access memory (not shown in figure). Abstraction getters 404 may be configured to query internal state of the underlying abstractions 316. Abstraction writers 406 (or intermediate representation writers) may be configured to perform transformations on the one or more abstractions or intermediate representations 316. The transformation may be performed based on a plurality of predetermined elementary transformations 408 and macro transformations 410. In various embodiments, the plurality of predetermined elementary transformations 408 may include one or more basic operations, such as addition, removal, or modification of the abstraction. Each transformation may be internally expressed as a sequence of one or more elementary transformations. For instance, an elementary transformation may include addition or removal of nodes or control-flow edges in an abstraction, such as a control flow graph abstraction. The transformation of the abstraction may involve modification of the state of the program.
The one or more elementary transformations 408 may be communicated to one or more stabilizers 212 of each abstraction 316. In various embodiments, each abstraction 316 may be associated with a stabilizer 212. The one or more stabilizers 212 may be configured to stabilize the one or more abstractions using the information captured by the elementary transformation used earlier. In various embodiments, a default universal stabilizer may be used as a base class of all program abstractions that stabilizes any program-abstraction using the fixed set of abstraction-specific fundamental operations.
In various embodiments, the abstraction writer 406 may be invoked only via the elementary transformations. The abstraction getters 404 of each program abstraction 316 may access the internal state of the corresponding abstraction only via a set of dedicated stabilizers 212, which ensure that every observable state of the abstraction is consistent with the current state of the intermediate representation of the program.
In various embodiments, each concrete program abstraction class may inherit from the abstract base class of program-abstractions (BasePA). The base class may include one or more common methods and data-structures necessary for self-stabilization. The stabilization process may be triggered by abstraction getters of each valid program-abstraction in response to a transformation. In various embodiments, a global set (allAbstractions) of the program abstractions may be maintained, and in the constructor of base class of program-abstractions (BasePA), which may be invoked implicitly during construction of every program-abstraction object A, a reference of A may be added to allAbstractions.
In the constructors of the base abstraction, one or more data structures local to the abstractions may be initialized. The one or more data structures may store information of edges added, edges removed, nodes added, and nodes removed during elementary transformations. The data structures may be needed for self-stabilization of the abstraction. An example of the constructor of BasePA may be given as:
In various embodiments, the stabilization of program-abstractions in response to the modifications performed by an optimization operation may be done by directly modifying the internal representations of the program-abstraction. Alternatively, and more preferably, the program-abstraction may perform the stabilization internally, i.e., the program-abstraction may be informed of the exact modifications which have been performed on the program.
In various embodiments, the predetermined elementary transformations may be used as the missing link between optimizations and program-abstractions. The predetermined elementary transformations may capture all the program modifications via the one or more fundamental operations. In each elementary transformation, the information about addition/deletion of nodes, control-flow edges, call-edges, and inter-task edges may be collected. The collected information may be sent to every program-abstraction object, present in the set allAbstractions.
A flow diagram for an alternating inspection phase and transformation phase of the code optimization process is illustrated in
A flow diagram of the steps performed during the inspection phase 502 by the abstraction getters 404 is illustrated in
A flow diagram of the steps performed during the transformation phase by the elementary transformation process is illustrated in
A flow diagram of the steps performed by the stabilizer of abstraction A is illustrated in
As illustrated in
In various embodiments, the plurality of abstractions 316 may include phase analysis (or concurrency analysis). In phase analysis if a node n that has been added to the program does not internally contain any global synchronization operation among threads, such as a barrier, then the phase information of the CFG neighbors of n may be reused to stabilize the phase information of n and its children. The node removal may also be done similarly. When the node being added or removed may contain a barrier, it may change the phase information (globally). Thus, the phase information may be re-computed from the beginning (by calling its initialization operations from analysis component 208). Note that if the phase stabilization leads to addition/removal of any inter-task edges, those edges may be captured in addedEdges/removedEdges sets.
A flow diagram for handling the impact of node addition on phase information by the phase stabilizer is illustrated in
Similarly, a flow diagram for handling the impact of node removal on phase information by the phase stabilizer is illustrated in
In various embodiments, the program abstractions 316 may include results for iterative data flow analysis (IDFA). The disclosed method provides a generic template that may be used to instantiate any IDFA (for example, points-to analysis) without any additional code to realize self-stabilization. In order to realize self-stabilization an internal set (seeds) of nodes, starting which the flow maps may need an update as a result of program transformations, may be maintained. The seeds set is populated in the methods (node removal/addition and edge removal/addition) with those nodes whose IN (or OUT) flow maps need to be recalculated due to the changes to their predecessors (or successors), in case of forward (or backward) analyses. The default (empty) implementation of common preprocessing may not be required to be overridden and common post-processing may be overridden to invoke self-stabilization procedure that takes seeds as argument.
A flow diagram of the IDFA stabilizer is illustrated in
A flow diagram of the first pass of IDFA stabilizer in block 1110 is illustrated in
A flow diagram of the second pass of IDFA stabilizer, for each node in the worklist with SCC id as scc-id, is illustrated in
The time and manner in which a program abstraction is stabilized under program modifications is important and the two choices for performing stabilization may be eager versus lazy and invalidate versus update.
On the basis of these two dimensions, the following four modes of stabilization for any program abstraction were assessed: (i) Eager-Invalidate (EGINV), (ii) Eager-Update (EGUPD), and (iii) Lazy-Invalidate (LZINV), (iv) Lazy-Update (LZUPD). The four modes of stabilization were then compared.
Eager versus lazy: In case of eager mode, for each program-abstraction (say A), an optimization involving k elementary transformations would lead to k invocations of its stabilizer (say, I1, I2, . . . , Ik). There may be many instances where A is not read between the invocations Ii . . . Ij (1≤i<j≤k). In such cases the invocations Ii, Ii+1, . . . Ij−1 of the stabilizer are redundant. In contrast, lazy-stabilization avoids such redundancies.
Invalidate versus update: Though the update modes seem much more efficient than the invalidate modes, in practice the difference in their performance depends on a number of factors, such as the number of program modifications, the complexity of the associated incremental update, and so on. Further, designing the update modes for certain program-abstractions is quite a challenging task. To address such issues, the self-stabilization compiler may support both invalidate, as well as update modes of (lazy) stabilization.
Note that while, in general, LZUPD seems to be the most efficient mode of stabilization in terms of performance, EGINV mode of stabilization is closest to the custom code that is generally written by the compiler writer in case of conventional compilers, especially in the absence of any notion of incremental update of relevant program-abstractions.
The self-stabilizing method was used by a compiler writer to efficiently design or implement new optimizations without having to write any extra code for stabilization of program-abstractions. To illustrate the benefits of using the disclosed compilation method, an involved optimization pass that reduces redundant barriers in OpenMP C programs was used.
The barrier remover method performs the following steps, as shown in the block diagram in
In contrast to the case of designing or implementing the method in the context of a traditional compiler, implementing the method in the context of self-stabilizing compilation requires only the implementation of the three optimization steps described above, and needs no explicit code for stabilization of the relevant program-abstractions. Furthermore, the optimization writer does not even have to specify what program-abstractions are needed to be stabilized. Therefore, the optimization writer remains oblivious to the questions like which abstraction need to be stabilized, where to invoke stabilization code, and how to stabilize each of the abstractions even in the context of an involved optimization.
The performance evaluations of the lazy modes of stabilization were conducted by studying the parameters related to compilation time in the context of the optimization discussed in Example 2.
An evaluation describing the impact of the lazy modes of self-stabilization on the compilation time of the above discussed benchmark programs while running barrier remover method is disclosed. For reference, in Table 1, columns 7-10 show the time spent (in seconds) in self-stabilization and the total compilation time, in the context of the EGINV and LZUPD modes of self-stabilization, while performing barrier remover. As discussed earlier, EGINV is arguably the simplest (and natural) way to achieve self-stabilization.
133.69
12.86
31.61
0.41
4183.77
213.64
The impact of EGUPD, LZINV, and LZUPD, is illustrated by showing their relative speedups with respect to EGINV, in terms of speedups in IDFA stabilization-time (see
LZUPD vs. EGINV: In case of speedups in the IDFA stabilization-time (
LZUPD vs. EGUPD: It is clear from
LZUPD vs. LZINV: As shown in
LZINV vs. EGUPD: As expected the performance comparison between LZINV and EGUPD throws a hung verdict, owing to benefits and losses due to lazy vs. eager and update vs. invalidate operations that are split between the two modes. Overall, LZINV outperformed EGUPD by a narrow margin (geomean speedup=1.2×).
Overall, the LZUPD mode leads to maximum benefits for stabilization time, across all four modes of stabilization. This in turn leads to significant improvement in the total compilation time, with speedup (compared to EGINV) varying between 1.08× to 10.4× (geomean=4.09×), across all the benchmarks (see columns 9 and 10 in Table 1, for the raw numbers). It was also seen that in most of the benchmarks LZUPD not only reduces the cost of stabilization, but also the rest of the compilation time ((column 9-column 7) vs. (column 10-column 8)), which was caused by the latent benefits (in cache, garbage collection and so on) arising due to significant reduction in memory usage (see columns 11 and 12).
The performance evaluation of the proposed lazy modes of stabilization was conducted by studying the parameters related to memory consumption, in the context of the optimization discussed in Example 2.
Table 1 (columns 11 and 12) shows the maximum additional memory footprint (in MB), in terms of the maximum resident size, while running barrier removal method from Example 2. The values were obtained by taking the difference of peak memory requirements during compilation with and without the optimization pass. The values shown were calculated with the help of /usr/bin/time GNU utility (version: 1.7).
The seeming discrepancy in EP and stencil is mostly an issue with the precision of measurement tool, where it is difficult to rely on the gains when the differences between the absolute values are small (in few tens of MB). Note that the tool is still effective in drawing a broad picture of the peak memory requirements. In clomp, the peak memory usage of LZUPD and LZINV are slightly higher (˜2%) than that of EGINV on analyzing the program using the java profiler jvisualvm, and this anomaly seems to be related to the behavior of the underlying GC, specifically on when the GC is invoked (impacts the peak memory-usage).
Overall, the proposed lazy modes of stabilization lead to significant memory savings compared to the naive EGINV scheme. This in turn can improve the memory traffic and overall gains in performance.
In order to empirically validate the correctness of the design/implementation of compiler and of points-to analysis, the points-to graphs for each benchmark under each mode of stabilization were verified. The state of final points-to graphs across all the four modes matched verbatim. For each benchmark, it was verified that the generated optimized code (i) does not differ across the four modes of self-stabilization, and (ii) produces the same output as that of the un-optimized code.
An empirical study for assessing the impact of the disclosed self-stabilizing compilation methods on writing different compiler passes, by comparing the coding efforts required to perform self-stabilization against manual stabilization, was performed. The study was performed in the context of various components of barrier removal optimization from Example 2.
A simple scheme to estimate the additional coding efforts that may be required to perform manual stabilization was used. The self-stabilizing compiler was profiled by instrumenting the implementations of barrier removal, as well as various program-abstractions, and the elementary transformations. By running this profiled compiler on each benchmark program, the following were obtained: (i) the set of change-points (or program points where an elementary transformation may happen) for barrier removal, and (ii) the set of program-abstractions that may be impacted by barrier removal. This data was used to estimate the manual coding efforts that may be required to overcome the problems when new abstractions and new optimizations were added.
In Table 2, the number of change-points discovered in the major components of barrier removal is enumerated.
In the absence of the disclosed method, the compiler writer would have to correctly identify these 90 change-points (i.e., on an average, almost 1 for every 28 lines of code) in barrier removal, and insert code for ensuring stabilization of the affected program abstractions. At each change-point, the compiler writer needs to handle stabilization of the impacted program-abstractions, irrespective of the chosen mode of stabilization. Ideally a program-abstraction A needs to be stabilized in response to the transformation at a change-point c1, if c1 is relevant for A. c1 is considered to be a relevant change-point for A, if A is read after the transformation performed at c1, and no other change-point is encountered in between. Thus the set of relevant change-points was used as a tighter approximation for the set of change-points after which A may have to be stabilized.
Table 3 lists the number of relevant change-points for each program-abstraction impacted by barrier removal; this data also was obtained from profiling the self-stabilizing compiler (profiling details discussed above).
Table 3 shows that there are significant number of places where this stabilization code needs to be invoked, in the absence of the disclosed method. For example, CFG stabilization needs to be performed at 57 places, and call-graphs at 49 places—which can lead to cumbersome and error-prone code. Further, upon addition of any new program-abstraction to the compiler, the compiler writer would have to revisit all the change-points of pre-existing optimizations (for example, 90 change-points for barrier removal) to check if the change-point may have necessitated stabilization of the newly added program-abstraction. In contrast, in the presence of the disclosed method, all the above tasks were automated—the compiler writer needed to spend no effort in identifying the places of stabilization, as the writer needs to add no additional code as part of the optimization in order to stabilize the program-abstractions.
On manually analyzing the code of barrier removal it was found that there are seven program-abstractions that were used and/or impacted by barrier removal. These are listed in Table 3. The non-zero numbers in column 4 show that the compiler writer indeed needs to invoke stabilization code for each of the seven program-abstractions during the execution of barrier removal. Thus, in case of manual-stabilization, on writing barrier removal, the compiler writer needs to identify these seven program-abstractions, from the plethora of available program-abstractions—a daunting task. Further, while adding any new program-abstraction A, the compiler writer needs to manually reanalyze barrier removal to check its impact on A. In contrast, in the presence of the disclosed method, these tasks are automated—the compiler writer needs to put no effort to identify the program-abstractions (existing or new) that may be impacted by an optimization pass.
For manual stabilization of a program-abstraction, the compiler writer chooses from any of the four modes of stabilization, or a combination thereof, as discussed earlier. Out of the seven program-abstractions that require stabilization by barrier removal, phase analysis and inter-task edges have been derived from YConAn, a concurrency analysis provided by Zhang and Dusterwald [2007, 2008]. It was not clear if a straightforward approach exists to support update modes of stabilization for YConAn. By inspecting the code of self-stabilizing compiler the amount of manual code required for stabilization of all the seven program-abstractions was estimated, as shown in Table 3. Upon adding a new program-abstraction, the compiler writer would need to write additional code manually for its stabilization. In contrast, in the context of the disclosed method, for the case of iterative data-flow analyses, such as points-to analysis (with 316 lines of code for manual stabilization) or any new IDFA-based program-abstraction, the compiler writer would not have to write any stabilization code. Therefore, in contrast to the traditional compilers, it was much easier to write optimizations or IDFA based analysis in the disclosed method, as the compiler writer does not have to worry about stabilization.
The disclosed method provides an optimization method to render various existing program-abstractions consistent with the modified program. The evaluation also shows that the disclosed method makes it easy to write optimizations and program analysis passes (with minimal code required to perform stabilization). Also, the lazy-update and lazy-invalidate stabilization choices lead to efficient compilers. The disclosed method provides guaranteed self-stabilization not just for the existing optimizations or program abstractions, but also for all the future optimizations or program-abstractions. The method provides explicit steps to ensure that the program-abstractions always reflect the correct state of the program at the time of being accessed, which in turn ensures the correctness of the inspection phases of the downstream optimizations, and hence the correctness of the generated output program.
Although the detailed description contains many specifics, these should not be construed as limiting the scope of the invention but merely as illustrating different examples and aspects of the invention. It should be appreciated that the scope of the invention includes other embodiments not discussed herein. Various other modifications, changes and variations which will be apparent to those skilled in the art may be made in the arrangement, operation and details of the system and method of the present invention disclosed herein without departing from the spirit and scope of the invention as described here.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202041054066 | Dec 2020 | IN | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IN2021/051108 | 11/26/2021 | WO |
