Актуальность работы. Современные компиляторы, как правило, включают сотни различных оптимизаций, которые, работая на разных этапах компиляции, влияют на качество сгенерированного кода. При этом набор оптимизаций (опций компилятора), при которых генерируется оптимальный объектный код зависит как от целевой архитектуры машины, так и от специфики выбранного приложения. Обычно разработчики и пользователи приложений используют параметры компилятора по умолчанию (например -О2 в компиляторах GCC и LLVM), определяющие базовые наборы оптимизаций. Такие наборы определяются разработчиками компиляторов известных наборов тестов (как правило, SPEC1) и обеспечивают компиляцию оптимального кода в среднем для данного набора. Обычно, для разных приложений оптимальные наборы опций компилятора могут различаться, в том числе, в зависимости от целевой платформы. При этом, для конкретного приложения можно значительно увеличить производительность только за счет правильного подбора параметров компилятора. Задача усложняется еще тем, что критериями оптимальности могут являться наряду с производительностью, также размер кода, энергопотребление, время компиляции и т.д. Кроме того, нередко требуется оптимизировать одновременно по нескольким критериям (например, по производительности и размеру кода). В некоторых случаях критерии могут не согласовываться между собой, и тогда приходится использовать компромиссные подходы. Подбор опций компилятора и значений параметров компиляции для конкретного приложения требует глубокого знания инфраструктуры компилятора и особенностей целевой платформы, поэтому для разработчиков и пользователей приложений, не специализирующихся в области компиляторных технологий, актуальны автоматические методы подбора параметров компиляции. Существующие инструменты автоматического подбора оптимизаций компилятора (в том числе с поддержкой многокритериального поиска) не удовлетворяют одновременно таким актуальным требованиям пользователей и разработчиков программного обеспечения как, например, поддержка подбора числовых параметров компиляции, многокритериальный поиск, параллельная кросс-компиляция и запуск на нескольких тестовых устройствах с целевой архитектурой. Обеспечить улучшение эффективности работы приложения можно также посредством корректировки исходного кода. Корректировка исходного кода библиотеки может повысить уровень применимости ряда межмодульных оптимизаций (например, открытая вставка между модулями) компилятора на этапе компоновки, так как многие библиотеки (особенно более старые) при написании не были рассчитаны на такие возможности компилятора. Некоторые библиотеки содержат некорректные объявления области видимости своих функций, что приводит к тому, что все глобальные функции самой библиотеки автоматически экспортируются в качестве ее интерфейса. Это препятствует выполнению межмодульных оптимизаций на этапе компоновки, так как эти функции могут быть вызваны из других библиотек во время выполнения кода. Корректировка соответствующих объявлений в библиотеках позволяет существенно повысить применимость оптимизаций на этапе компоновки и соответственно улучшить производительность и уменьшить размер кода, при этом не нарушается целостность библиотеки. Modern compilers typically include hundreds of different optimizations that are working on different stages of compilation thus affecting the quality of the generated code. Wherein the set of optimizations (compiler options), during which the most optimal object code is generated, depends on both the target machine architecture, and the specifics of the selected application. Typically, developers and users of applications use default compiler options (such as -O2 in the GCC and LLVM), defining the basic set of optimizations. Such sets are determined by the developers of compilers for popular test suites (usually, SPEC) and ensure optimal code compilation on average for the given test suite. It is well known that for various apps the "best" set of optimizations can vary, moreover, depending on the target platform and for a particular application can be enhanced its performance by several dozen percent only by the proper selection of the compiler parameters. The problem is complicated also by the fact that the optimality criteria along with performance, as well can be code size, power consumption, compile time, etc. Besides, often it is required to optimize simultaneously for multiple criteria (e.g. performance and code size). In some cases criteria may not be compatible with each other and then we have to use some trade-offs. Selection of compiler options and compilation parameter values for the specific application requires a deep knowledge of the infrastructure of the compiler and features of the target platform. For regular developers and users of applications the automated methods for selecting the parameters of compilation are of great interest. These methods are implemented in the existing instruments, but in many instruments, some useful features such as multi-criteria search, support of parallel cross-compile and run on the target platform, etc., are not implemented. To improve the efficiency of the application can also be done by correcting the source code. For example the correction of the library’s source code can improve the applicability of a number of inter-module optimization (such as an inlining between the modules) of the compiler at link time, since many libraries (especially older ones) were not designed for compiler with link-time capabilities. Some libraries contain inappropriate declarations in the scopes of its functions, which leads to the fact that all the global functions of the library are automatically exported as its interface. This prevents the implementation of inter-module optimizations at link time, since these functions can be called from outside the runtime code. Correction of respective declarations in libraries can significantly enhance the applicability of optimizations at link time and thus improve the performance and reduce code size.
Ժամանակակից կոմպիլյատորները սովորաբար պարունակում են հարյուրավոր տարբեր օպտիմիզացիաներ, որոնք աշխատելով կոմպիլյացիայի տարբեր փուլերում, ազդում են գեներացվող մեքենայական կոդի որակի վրա: Ընդ որում՝ օպտիմիզացիաների հավաքածուն (տարբերակը), որի ժամանակ գեներացվում է առավել օպտիմալ օբյեկտային կոդ, կախված է ինչպես մեքենայի նպատակային ճարտարապետությունից, այնպես էլ ընտրված ծրագրային հավաքածուի առանձնահատկություններից: Սովորաբար ծրագրային համակարգեր մշակողներն ու նրանցից օգտվողները կիրառում են կոմպիլյատորի օպտիմիզացիաների բազային հավաքածուները (օրինակ “-02” GCC և LLVM կոմպիլյատորների համար): Այդ հավաքածուները որոշվում են կոմպիլյատորներ մշակողների կողմից հայտնի թեստային հավաքածուների համար (որպես կանոն SPEC)՝ ապահովելով տվյալ հավաքածուի շրջանակներում միջինում օպտիմալ կոդի գեներացիա: Ինչպես հայտնի է, ծրագրային տարբեր հավաքածուների համար լավագույն օպտիմիզացիաների հավաքածուները կարող են տարբերվել, այդ թվում՝ կախված նպատակային պլատֆորմայից, և կոնկրետ ծրագրային հավաքածուի համար տասնյակ տոկոսներով կարելի է մեծացնել արտադրողականությունը, միայն թե պետք է ճիշտ ընտրված լինեն կոմպիլյատորի պարամետրերը: Խնդրի բարդությունը պայմանավորված է նրանով, որ բացի արտադրողականությունից՝ օպտիմալության չափորոշիչներ կարող են լինել նաև կոդի չափը, էներգաօգտագործումը, կոմպիլյացիայի ժամանակը և այլն: Բացի այդ՝ հաճախ պահանջվում է օպտիմիզացնել՝ միաժամանակ ըստ մի քանի չափորոշիչների (օրինակ՝ արտադրողականության և կոդի չափի): Որոշ դեպքերում չափորոշիչները կարող են լինել անհամատեղելի, և այդ դեպքում ստիպված կիրառվում են համատեղման ընդունելի մոտեցումներ: Ծրագրային կոնկրետ հավաքածուի համար կոմպիլյատորի տարբերակների և կոմպիլյացիայի պարամետրերի արժեքների ընտրությունը պահանջում է խորը գիտելիքներ կոմպիլյատորի ենթակառուցվածքի և նպատակային պլատֆորմայի առանձնահատկությունների պարագայում: Սովորական մշակողների և ծրագրային հավաքածուներից օգտվողների համար ակտուալ են կոմպիլյացիայի պարամետրերի ընտրության ավտոմատ մեթեդները: Այդպիսի մեթոդներ իրականացված են ծրագրային համապատասխան գործիքներում, բայց դրանց մի մասում բացակայում են որոշ օգտակար հատկություններ, որոնցից են, օրինակ, բազմաչափորոշիչային փնտրումը, զուգահեռ կրոսս-կոմպիլյացիայի իրականացումը նպատակային պլատֆորմի վրա և այլն: