Добрый день всем.
Давно хотел получать оптимизированный код, все руки не доходили. Сейчас начинаю проект с нуля, самое время начать осваивать. Первым делом начал с эзернета, запустил без оптимизации, пинги проходят. Затем ставлю уровень 3, смотрю что получилось.
Вот кусок из ETH_STM32F2xx:

Обе переменные объявлены локально внутри функции и вроде должны вести себя одинаково. Но если шагать отладчиком, видно, что id1=0x22, а вот id2=not in scope. Почему не отображается id2? Да и много чего не могу посмотреть отладчиком, но видимо все работает правильно, раз плата пингуется. Как тогда отлаживать при включенной оптимизации?

Никак. Отлаживать нужно на самом низком уровне оптимизации. Когда всё работает, повышаем уровень оптимизации до максимального и надеемся, что ничто не сломается. Соответственно, изначально код пишем так, чтобы при повышении уровня оптимизации не вылазили баги (это чаще всего относится к своевременному применению volatile, а также избегаем зависимость от скорости исполнения). Также надеемся, что нет багов в компиляторе.
Если ну очень хочется поотлаживать оптимизированный код, то делаем это через дизассемблер, что может быть очень трудоёмко для нетривиального кода.
Как-то так.

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

В этой ситуации (хватает и памяти, и скорости) оптимизация не даёт ничего.
Однако, если вы рассчитываете использовать написанный код в других проектах, в которых может быть включен высокий уровень оптимизации, тестирование кода с включенной оптимизацией может помочь заранее отловить баги, зависящие от уровня оптимизации. То есть по сути дополнительное тестирование как инвестиция в будущее повторное использование кода.

Спасибо, scifi, за полезную информацию.

Полностью согласен с scifi. Могу только добавить, что включение полной оптимизации полезно в выявлении скрытых багов, которые могут проявиться при её включении. Если её не включать, то баг останется, но не будет проявляться до некоторого момента, пока так сложатся звёзды на небе и переменные в map-файле, что и без оптимизации перестанет работать, но тогда уже будет непонятно где искать баг.
При полной оптимизации обычно более полно используются регистры, да и вообще - код более перетасовывается, что часто помогает скрытым багам вылазить наружу.
Всё сказанное конечно не относится к случаю если оптимизатор криво реализован в компиляторе. В таком случае оптимизацию вообще нельзя включать.