Ако компилаторът е достатъчно умен (а те напоследък почти всичка са) и е с подходящите настройки може да замени викането на всяка функция направо с кода който е във функцията, след това да изследва къде параметрите са константни и съответно винаги ще има един и същи резултат и да махне кода който никога няма да се изпълни. Предотвратява се с махане на оптимизации, ползването на volatile също помага но то е малко по различно нещо.

Въпросът не е теоретичен нито "теоретичен". Какво ще бъде поведението на оптимизатора е въпрос на имплементация на съответния оптимизатор. И за различните компилатори има различни заклинания.
Както Палавров казва, най-напред се прочита документацията на компилатора - частта за контролиране на оптимизациите с конфигуриране или с ключове в команден ред. Ако намериш подходящ ключ, може да го зададеш за отделен файл в който да разположиш само тези функции и така промяната в оптимизациите да не засяга глобално целия проект. Някои компилатори имат екстеншъни,специфични квалификатори, които могат да се поставят към самата функция в сорс кода и така да не се налага да местиш функциите в друг файл.
Има също така и разни заклинания или хватки, които могат просто да попречат на оптимизатора да бъде толкова агресивен на точно определени места, там където искаш. Но това е въпрос въобще не-теоретичен и ако нямаш опит с компилатора(оптимизатора), който ползваш, се прави на принципа проба-грешка.
например ред:

ще добави един NOP, но и ще раздели кода на две и оптимизатора ще бъде принуден да оптимизира поотделно тези две части.
Ако искаш не-"теоретичен" отговор трябва да кажеш кой е компилатора, който в момента използваш.

В момента превеждам един проект от асемблер на C, средата е IAR EW.
Целта ми е да преведа кода, опитвам се да отделя спецификите на IAR .
Крайната цел е преход към друг процесор и евентуално друг компилатор.

Функции 2/3/4 ще бъдат премахнати само ако нямат странични ефекти.
Дали функция 1 ще бъде заместена с inline код - вече зависи от компилатор и опции.

Набързо прегледах - IAR има #pragma optimize= .... което се отнася за следващата функция,
MPLAB XC16 има нещо, което се вписва между типа и името на функцията. Тоест някакво решение на ниво препроцесор има.
Сега Woody ме хвърли в недоумение. Малко ми е неясно какво разбира под странични ефекти.
func2 , 3 манипулират някакви данни, вкл. четене/запис от външна памет. Не връщат резултат.
Func1 връща винаги резултат "1". Цялата функция има винаги резултат "1" , независимо от изпълнението на ф2 и ф3. Та от някаква гледна точка func1 може да бъде премахната и заменена с
"return 1"(нещо различно от inline , както аз го разбирам) . Което ми пречи.

https://en.wikipedia.org/wiki/Side_effe ... er_science)

Не се притеснявай, компилаторите се усещат в такива ситуации и ще оставят всичкия код който има страничен ефект т.е. модифица статични променливи директно или през указател - особенно през указател повечето компилатори веднага вдигат ръце и се отказват да анализират надълбоко. За volatile също имаш гаранция, че няма да премахне никакъв код.

Единственото за което не съм много сигурен дали не трябва да се погрижиш сам е когато четеш разни регистри на процесора което предизвиква хардуерни последствия - примерно пипа разни флагове за FIFO статуса на серийните портове след като прочетеш поредният пристигнал байт и го игнорираш - т.е. от гледна точка на C компилатора не правиш нищо съществено и може да се полакоми да ти изреже кода.

Да ти кажа от моята практика досега в такива ситуации ми е помогнало най много да гледам дизасм на компилирания код - така всякакви въпроси си намират отговора и човек му свиква на компилатора кога какво си позволява да прави

Palavrov,
думата volatile ..какво искаш да кажеш, не се ли отнася/прилага само за данни?
Не схващам как я прилагаш към моя въпрос.

Volatile кара компилатора да не кешира съответното място от паметта защото то може да си промени стойността в всеки един момент. Т.е. така много от оптимизациите около този код ще бъдат подтиснати. Освен това в някои диалекти на Ц може да се маркира освен памет също и код - това кара компилатора да махне всички кешира и променливи от регистрите на процесора т.е. чупи една камара оптимизации. Ако ти е интересно потърси за memory barrier

За моето приложение едва ли ще ми трябва това.


Сега да задам още един въпрос.
Няколко прекъсвания са свързани с един обМщ вектор , съответно ISR е switch по някаква дума от хардуерния модул. Например - от един таймерен модул с няколко кепчър/компаратора имам примерно три неща - светкане на лампичка, приемане на бит ,предаване на бит за софуерен УАРТ.
Съответно трите неща могат да бъдат направени в ISR. Могат да бъдат направени и като функции, викани от ISR. Последното - естествено не се препоръчва...обаче си има плюсове. При смяна на процесора - трите неща могат да отидат на съвсем различни места, и затова ми се иска да ги отделя като функции, викани от интеръпт. Добре , но не намирам нищо съществено по въпроса - нито в упътването на IAR, нито на Майкрочип. По форумите мернах за Майкрочип- има дума reentrant като
атрибут на функция, но в описанието на XC16 не го намерих.
В IAR част от регистрите се наричат scratch и могат да бъдат ползвани, без да се запазват/възстановяват. Това ме кара да се чудя, как мога да съм сигурен - че виканите функции ще запазят всички регистри.

ако данните или указателя чрез който ги достъпваш е деклариран с volatile квалификатор това е сигнал за компилатора, че някой друг може да пипа по тях или някой друг чете от тях - т.е. възможен side effect. и няма как компилатора да реши само на базата на сорса, който обработва и да премахне кода на тези функции чрез оптимизация нито пък да размести реда в който си ги написал за извикване.

XC16 е gcc. За да не запазва при викане на някоя функция контекста(регистрите) трябва да го укажеш __attribute__((naked)) Когато функцията е обработчик на прекъсване също се задава по някакъв начин с екстеншън примерно __attribute__((interrupt("IRQ"))).
Във всички останали случаи компилатора ще се погрижи за запазване-възстановяване на контекста. Така че няма да се чудиш. Или намираш и четеш ABI application binary interface или както palavrov вече каза - компилираш и гледаш дизасемблирания бинарен код. Т.е. стъпка по стъпка градиш доверие със съответната имплементация на С компилатор.

В общи линии ме поуспокоихте.
Благодаря!

XC16
void __attribute__((optimize("-O0"))) foo(){ ... }