The structure of Universal Translating Library (UTL) is divided into two parts: analytical part and Program Data Base (PDB). Analytical part is the basis of the library. It contains implementation of analysis and optimization algorithms, abstracted from concrete programming languages and computing platforms. PDB contains drafts for semantic description of evaluated program and resources description of target platform. These two parts are interacted with each other through well-defined interfaces that are named by us interfaces of access to semantic program. These interfaces are declared in analytical part of UTL and defined in PDB.

PDB includes IR that is flexible and well-tuned for various existing and non-existing (e.g. GIMPLE in gcc) target platform. Also it includes methods for saving and restoring of IR. To avoid terminological mess we name IR in analytical part of UTL as Analytical Representation and IR in PDB as Semantic Representation. At the moment we implemented methods of saving/restoring IR on xml-file. This facilitates using and debugging offered technology. We name IR that is saved on file or wherever else as Program Data Base Source (PDBS).

Semantic representation can be built not only on the base of PDBS. If user has his own IR, it can be converted to semantic representation of PDB.

Building Blocks

There are three ways of UTL interaction with user’s translating system.

First one: user IR is represented in a form of PDBS after that semantic and analytical representations are built. After applying UTL analyses and optimizations, semantic representation is transformed back to PDBS, from which user IR is restored.


Second way: building semantic representation from user IR without using PDBS. After applying UTL analyses and optimizations user IR is built from semantic representation.


And the last way: building of analytical representation immediately from user IR without semantic representation using.


First way allows to totally divide user product from UTL that decides, in particular, license problem. The second and third ways require linking UTL with user system. These ways make the working of final product essentially more effective. The use of second way is more convenient for creating new translating system. The third one is supposed to be used during modernization of existing system that has its own IR.

To incorporate automatic parallelizer implemented by us on the base of UTL into GCC, we chose the first way. This required creating of PBDS that gives, in particular, possibility to work GCC and UTL on different platforms. Besides, it made automatic parallelizer free from GNU Public License that gives possibility to sell it as a commercial product.


Efficiency of UTL working on parallel computing systems.

Specificity of UTL design allows to start a few analysis and/or optimization algorithms simultaneously working on different regions of the compiled program. A “region” means some part of compiled program. Depending on context it can be module, routine, loop, basic block and etc.