Проверка уровня оптимизации Опции

[juvf]

Есть проект. в нем один файл должен быть только с оптимизацией -О0, а другой только с оптимизацией -Ohs. Иначе прога не будет правильно работать. Как во время компиляции проверить, что к этим файлам применён нужный уровень компиляции?

есть проверки типа

Код

#ifndef configUSE_TICK_HOOK
    #error Missing definition:  configUSE_TICK_HOOK should be defined in FreeRTOSConfig.h as either 1 or 0.  See the Configuration section of the FreeRTOS API documentation for details.
#endif

Хотелось бы что-то подобное. если уровень оптимизации не тот, то выдать еррор и завершить компиляцию/сборку.

[juvf]

Есть место в программе, например обработчик прерывания.... без оптимизации один си-оператор есть 6 асм команд. без оптимизации почти 90% времени уходит на обработчик. прога не работает. с макс ур оптимизации по скорости этого обработчика си-оператор есть 4, а то и 2 асм команды. в итоге в прерывании 40-50% времени. прога работает без сбоев.

а то место, где optimize=none.... там используются дефайны регитров, библиотечные. можно канечно свои определить, обставить всё валатайлами.... в итоге асм получится 1в1 как с optimize=none. смысыл перелопачиать библиотечные дефайны и тратить время на "красивый код", если optimize=none решает проблему?

Стоит решать проблему а не следствие.

Проблема в том, что оптимизатор оптимизирует этот код. Отключить оптимизацию можно волотайлами или optimize=none. кому что милее

[adnega]

Есть место в программе, например обработчик прерывания.... без оптимизации один си-оператор есть 6 асм команд. без оптимизации почти 90% времени уходит на обработчик. прога не работает. с макс ур оптимизации по скорости этого обработчика си-оператор есть 4, а то и 2 асм команды. в итоге в прерывании 40-50% времени. прога работает без сбоев.

Еще в деле увеличения производительности очень помогает выравнивание данных. Все 8-ми и 16-ти битные данные нужно заменить на 32-битные.
Массивы копировать или очищать сразу по 32 бита. Ну и главный козырь - попробовать перенести рутину на аппаратные блоки (DMA, таймеры, SPI и т.п.)
Как правило, чем жирнее обработчик (а это на самом деле должно насторожить), тем больше возможностей для оптимизации. Крошечный обработчик можно
и ручками (читай на asm) написать. Вообще архитектура проекта должна быть заточена под эти "критические" обработчики.
Если не считать выключенную оптимизацию, то разница между результатом для разных уровней оптимизации (при оптимальном на C-уровне коде) не значительна. Точне не 2 раза.

а то место, где optimize=none.... там используются дефайны регитров, библиотечные. можно канечно свои определить, обставить всё валатайлами.... в итоге асм получится 1в1 как с optimize=none. смысыл перелопачиать библиотечные дефайны и тратить время на "красивый код", если optimize=none решает проблему?
Проблема в том, что оптимизатор оптимизирует этот код. Отключить оптимизацию можно волотайлами или optimize=none. кому что милее

В данном случае отсутствие volatile у регистров преступление. Нужно править библиотеку. Насчет 1в1 не полностью верно, ведь кроме доступа к регистрам есть и другой код. Выключение оптимизации не решение, т.к. при обращении из разных кусков программы (в том числе и с включенной оптимизацией) поведение будет разным. Может, вместо "optimize=none"/"optimize=yes" при каждом обращении к переменной в критичном к скорости модуле легче в одном месте написать volatile и иметь рабочий код при любом уровне оптимизации?

[juvf]

Ну и главный козырь - попробовать перенести рутину на аппаратные блоки (DMA, таймеры, SPI и т.п.)

Естественно. Но задач столько впихнули в этот проект и попытались его седать не на intel i7, а на проце попроще. экономика должна быть экономной. аппаратные блоки и без этого нагружены по максимуму.

[adnega]

Естественно. Но задач столько впихнули в этот проект и попытались его седать не на intel i7, а на проце попроще. экономика должна быть экономной. аппаратные блоки и без этого нагружены по максимуму.

А что за процессор Вы используете, если не секрет?

[AHTOXA]

А что за процессор Вы используете, если не секрет?

Присоединяюсь к вопросу. Мне тоже очень интересно, производитель какого контроллера не озаботился словом volatile в описании регистров.