optimization - Is a C++ optimizer allowed to move statements across a function call? -

optimization - Is a C++ optimizer allowed to move statements across a function call? -

note: no multithreading @ here. optimized single-threaded code.

a function phone call introduces sequence point. (apparently.)

does follow compiler (if optimizer inlines function) not allowed move/intermingle instructions prior/after function's instructions? (as long can "proove" no observable effects obviously.)

explanatory background:

now, there nice article wrt. benchmarking class c++, author stated:

the code time won’t rearranged optimizer , lie between start / end calls now(), can guarantee our timing valid.

to asked how can sure, , nick replied:

you can check comment in reply http://codereview.stackexchange.com/a/48884. quote : “i careful timing things not functions because of optimizations compiler allowed do. not sure sequencing requirements , observable behavior understanding of such program. function phone call compiler not allowed move statements across phone call point (they sequenced before or after call).”

what abstract callable (function, lambda, block of code surrounded lambda) , have signle phone call callable(factor) within measure construction acts barrier (not barrier in multithreading, believe convey message).

i quite unsure this, quote:

with function phone call compiler not allowed move statements across phone call point (they sequenced before or after call).

now, under impression when optimizer inlines function (which may case in (simple) benchmark scenario), free rearrange whatever likes long not impact observable behavior.

that is, far language / optimizer concerned, these 2 snippets exactly same:

void f() { // stuff / multiple statements } auto start = ...; f(); auto stop = ...;

vs.

auto start = ...; // stuff / multiple statements auto stop = ...;

now, under impression when optimizer inlines function (which may case in (simple) benchmark scenario), free rearrange whatever likes long not impact observable behavior.

it absolutely is. optimizer doesn't need inline occur in theory.

however, timing functions observable behaviour- specifically, i/o on part of system. optimizer cannot know that i/o produce same outcome (it won't) if performed in different order other i/o calls, can include non-obvious things memory allocation calls can invoke syscalls memory.

what means , large, function calls, optimizer can't great deal of re-arranging because there's potentially vast quantity of state involved can't reason about.

furthermore, optimizer can't know re-arranging function calls create code run faster, , create debugging harder, don't have great deal of incentive go screwing around program's stated order.

basically, in theory optimizer can this, in reality won't because doing massive undertaking not lot of benefit.

you'll encounter conditions if benchmark trivial or consists virtually exclusively of primitive operations integer addition- in case you'll want check assembly anyway.

c++ optimization inline order-of-evaluation