Устранение избыточных загрузок регистра GOT? - PullRequest
1 голос
/ 22 февраля 2011

Я имею дело с некоторым кодом, который на 70-80% медленнее при компиляции в виде PIC (позиционно-независимый код), и ищу способы облегчить проблему.Большая часть проблемы заключается в том, что gcc настаивает на вставке следующего в каждую функцию:

call __i686.get_pc_thunk.bx
addl $_GLOBAL_OFFSET_TABLE_,%ebx

, даже если это составляет 20% от содержимого функции.Теперь ebx является регистром, сохраняющим вызов, и каждая функция в соответствующем модуле перевода (исходный файл) загружает его с адресом GOT, и легко обнаружить, что функции staticне может быть вызван извне блока перевода (их адреса никогда не принимаются).Так почему же gcc не может просто загрузить ebx один раз в начале больших функций внешней связи и сгенерировать функции статической связи, чтобы они предполагали, что ebx уже загружен с адресом GOT?Есть ли какой-либо флаг оптимизации, который я могу использовать, чтобы заставить gcc сделать эту очевидную и масштабную оптимизацию, за исключением того, что встроенные ограничения поднимаются до небес, чтобы все было встроено во внешние функции?

Ответы [ 2 ]

2 голосов
/ 22 февраля 2011

Вероятно, нет никакого общего лекарства от этого, но вы можете попытаться поэкспериментировать с опциями встраивания.Я предполагаю, что static функции в модуле компиляции не имеют слишком много вызывающих, поэтому издержки на репликацию кода не будут слишком большими.

Самый простой способ заставить такие вещи с помощью gcc будетбыть, чтобы установить attribute((always_inline)).Вы можете поэкспериментировать с макросом, зависящим от gcc, чтобы обеспечить переносимость.

Если вы не хотите изменять код (но в любом случае static inline было бы хорошо), вы можете использовать опцию -finline-limit для точной настройки.что.

1 голос
/ 22 февраля 2011

Не совсем решение, но: если рассматриваемые функции не ссылаются на переменные области файла, вы можете собрать их все вместе в одном модуле перевода и скомпилировать без флага -fPIC. Затем вы связываете их вместе с другими файлами в конечном SO, как обычно.

...