Расход RAM в зависимости от уровня оптимизации, Для ARM, а может и для всех Опции

[kan35]

Разрабатываю ПО на STM32 с использованием FreeRTOS, и заметил, что при компиляции без оптимизации кода происходит не только раздутие памяти программ, но и идет увеличенный расход памяти RAM в стеках. Видимо под все переменные выделяется гарантированное место в стеке на все время жизни задачи, а когда оптимизация включена, то видимо переменные убиваются и возникают динамично, подчищая стек за собой. Правильно ли я это понимаю?

Если так, то конечно с этим можно смириться, но крайне неудобно, что с определенного момента debug target перестает работать, так как случается нехватка стека, при этом прога сваливается в самом начала жизни потока, то есть переменные видимо как то разом инициализируются... При этом release отлично работает, но отлаживаться сложнее.

[scifi]

Видимо под все переменные выделяется гарантированное место в стеке на все время жизни задачи, а когда оптимизация включена, то видимо переменные убиваются и возникают динамично, подчищая стек за собой. Правильно ли я это понимаю?

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

Если так, то конечно с этим можно смириться, но крайне неудобно, что с определенного момента debug target перестает работать, так как случается нехватка стека, при этом прога сваливается в самом начала жизни потока, то есть переменные видимо как то разом инициализируются... При этом release отлично работает, но отлаживаться сложнее.

Ну да, обычное дело. Точно так же в режиме отладки код может просто не поместиться в память программ.

[Dog Pawlowa]

Да-да, бывает, что с неполной оптимизацией программа вообще неработоспособна - прерывания наползают друг на друга
Вечная проблема резерва ресурсов.
Обычное правило - фактор 2. По памяти, по программной памяти, по быстродействию.
И все будет хорошо.

[KRS]

а я у IAR всегда ставлю максимальную оптимизацию и для отладки и для релиза! потому что IAR при максимальной оптимизации генерирует совсем другой код, многое выбрасывает, надо везде где надо использовать volatile и т.п. и что бы не пришлось отлаживать два раза...
А отладчик нормально работает и при максимальной оптимизации, в крайнем случае можно и по асму пройтись.

[Непомнящий Евген...]

Присоединяюсь. Отлаживайте релиз - код совсем другой, могут быть разные наборы багов

Если какой-то кусочек после оптимизации уж совсем непонятен - добавьте сохранение результатов в промежуточные переменные (volatile) или пометьте его неоптимизируемым.