Jump to content

    

Keil: оптимизация -O3 + -Ot ломает логику программы

1 час назад, Forger сказал:

Вы не понимаете - внутри вызываемой через делегат функции, могу быть другие вызовы. На этапе компиляции компилятор не может правильно выстроить дерево вызовов через такие указатели. Это можно сделать только в runtime.

И какая разница что там другие вызовы? У вас и в release и в debug - есть вызовы. И вы думаете что в случае release у вас будут вызываться одни функции, а в случае debug - другие? И что будет чёткая зависимость - в случае debug всегда будут вызываться функции с бОльшим стеком? Только в этом случае суммарное использование стека получится больше.

Или всё-таки вызов любой функции (из тех что могут вызываться косвенно) равновероятен что в debug  что в release?

Цитата

Статическое дерево вызовов тут просто бесполезно.

Причём тут "статическое дерево вызовов"? Вы это сами придумали, приписали это мне, и теперь пытаетесь со мной спорить. Я не говорил ни о каком "статическом дереве".

1 час назад, Forger сказал:

Я понимаю, что бодаться будете до последнего :dash3:    Замечено неоднократно ))

Бодаетесь пока что Вы сами с собой. С приписанными мне утверждениями.

Share this post


Link to post
Share on other sites
38 minutes ago, jcxz said:

И какая разница что там другие вызовы? У вас и в release и в debug - есть вызовы. И вы думаете что в случае release у вас будут вызываться одни функции, а в случае debug - другие?

Да, в в среднем вызовы одинаковые, код неизменный.

 

Quote

И что будет чёткая зависимость - в случае debug всегда будут вызываться функции с бОльшим стеком? Только в этом случае суммарное использование стека получится больше.

Или всё-таки вызов любой функции (из тех что могут вызываться косвенно) равновероятен что в debug  что в release?

Самое вероятное, почему размер стека жрется в debug, это полное отсутствие оптимизации вызовов некоторых простых функций и применяемых локальных переменных, которые при оптимизации могут заменяться просто регистрами ядра.

 

 

 

Quote

Причём тут "статическое дерево вызовов"? 

Имеется ввиду дерево вызовов, которое формирует компилятор на этапе компиляции. Все же правильнее будет назвать compile-time дерево.

Но в моих проектах оно бесполезно. Поэтому проанализировать стек с его помощью не получится.

 

Share this post


Link to post
Share on other sites
3 часа назад, HardEgor сказал:

Rebuld делали?

Просто убрать все галки на дополнительные файлы, перебилдидь, поставить все галки, перебилдить.

Удалить .uvguix. файлы.

Попробовать ручками удалить папку с всеми промежуточными и дополнительными файлами, а потом сделать build.

Ребилдол пил, не помогает.

Галки убирал/ставил, удалял папки с выходным шлаком, убирал/ставил галки снова - ноль реакции.

.uvguix завтра попробую удалить и посмотрю, что поменяется. А то совсем как-то с такой средой не разгонишься:beee:

Share this post


Link to post
Share on other sites
5 minutes ago, Arlleex said:

А то совсем как-то с такой средой не разгонишься:beee:

Да, KEIL - морально устарел, тут что есть, то есть ((

Share this post


Link to post
Share on other sites
1 час назад, Forger сказал:

Самое вероятное, почему размер стека жрется в debug, это полное отсутствие оптимизации вызовов некоторых простых функций и применяемых локальных переменных, которые при оптимизации могут заменяться просто регистрами ядра.

А не пробовали сравнить -o1 и -o3? При -o1 уже есть минимальная оптимизация.

1 час назад, Forger сказал:

Имеется ввиду дерево вызовов, которое формирует компилятор на этапе компиляции. Все же правильнее будет назвать compile-time дерево.

В том фрагменте .lst что я приводил, в разделе "stack usage" указаны размеры стека занимаемого только самой функцией, а не всем деревом её вызова. Всё дерево я не знаю - умеет ли IAR считать. Поэтому там легко сравнить функции в разных вариантах компиляции. 

23 минуты назад, Arlleex сказал:

А то совсем как-то с такой средой не разгонишься:beee:

IAR вам поставить нельзя?

Share this post


Link to post
Share on other sites
2 minutes ago, jcxz said:

А не пробовали сравнить -o1 и -o3? При -o1 уже есть минимальная оптимизация.

Пробовал, но нужные данные уже не отображаются средой ((

Видать оптимизатор на -o3 напрочь удаляет все структуры, которые использует среда для анализа этих данных.

 

2 minutes ago, jcxz said:

В том фрагменте .lst что я приводил, в разделе "stack usage" указаны размеры стека занимаемого только самой функцией, а не всем деревом её вызова. 

В Keil этого нет, по крайней мере мне не удалось получить аналогичные данные ((

 

 

Share this post


Link to post
Share on other sites
8 часов назад, jcxz сказал:

IAR вам поставить нельзя?

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

 

P.S. .uvguix снес, папки лишние снес, открыл проект, убрал галки "Debug Information", "Create HEX File" и "Browse Information". Ребилдол.

Снова установил галки обратно, ребилдол. Go to definition на любой определенный символ - та же самая красная хреновина внизу моргает...

Не может ли это быть из-за того, что Keil у меня крякнутый?

Share this post


Link to post
Share on other sites
23 минуты назад, Arlleex сказал:

P.S. .uvguix снес, папки лишние снес, открыл проект, убрал галки "Debug Information", "Create HEX File" и "Browse Information". Ребилдол.

Снова установил галки обратно, ребилдол. Go to definition на любой определенный символ - та же самая красная хреновина внизу моргает...

1. попробовать откатить версию компилятора или накатить новую (я сейчас текущий проект попробовал собрать на v5.06 update 1 build 61 - проблем нету, все definition  показывает)

2. если есть контроль версий, то посмотреть что изменилось в свойствах проекта

3. собрать проект заново(мне так два раза приходилось делать).

4. какие-то сторонние проблемы - кончилось место на диске, в путях есть русские буквы или пробелы и т.д.

 

Вспомнил что тема уже всплывала:

 

Share this post


Link to post
Share on other sites
10 часов назад, Forger сказал:

 

Цитата

В том фрагменте .lst что я приводил, в разделе "stack usage" указаны размеры стека занимаемого только самой функцией, а не всем деревом её вызова. 

В Keil этого нет, по крайней мере мне не удалось получить аналогичные данные (( 

 

 

Вместе с hex-файлом создается html-файл проекта, в котором указан максимальный размер стека (без учета косвенных вызовов и прерываний) и размер стека для каждой функции (в том числе и дерево вызовов)

Share this post


Link to post
Share on other sites
1 час назад, HardEgor сказал:

1. попробовать...

2. ...

...

Спасибо. Я попробую что-нибудь пошурудить.

Может даже среду нафиг снесу и переставлю.

 

P.S. Тот тред помню, это на домашнем компе все ок. А на работе какое-то шаманство:prankster2:

Share this post


Link to post
Share on other sites
50 minutes ago, Edit2007 said:

Вместе с hex-файлом создается html-файл проекта, в котором указан максимальный размер стека (без учета косвенных вызовов и прерываний) и размер стека для каждой функции (в том числе и дерево вызовов)

На html не обратил внимания, спасибо !

 

Короче, вот свел в таблицу ниже.

Отдельно по задачам нет данных, но в общем кое-что есть (см. OS::AbstractThread)

 

1.thumb.jpg.9b31d41c5b2ea02c28177d8eff2d45c1.jpg

 

Очевидно, что без оптимизации даже inline функции все равно формируются как полноценный вызов. Стек в итоге пожирается без всяких ограничений.

 

Самая оптимальная получается по ходу balanced, что в целом логично.

Поэтому в debug лучше ставить максимум -o1 (для некоторых -o0), а в release - balanced. Что собственно до этого я и делал )

 

ps компилятор v6.13.1

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now