Есть прога откомпилированная в VC(вроде, с какими ключами не знаю). В коде используется механизм: между операцией сравнения и условным переходом вставляются другие команды, если есть (например, пуш, мув и т.п.). Компилю исходники этой же проги и получаю всегда cmp и за ним сразу условный переход. Каким образом это влияет на оптимизацию? Какими ключами добиться такого эффекта?
На современных компах - никаким или никоим Т.к. все переходы выполняются спекулятивно на основе предыдущей истории переходов и соотв-но переход\непереход происходит сразу не дожидаясь результата сравнения, более того за счет внеочередного (out-of-order) исполнения "переход" может даже выполниться раньше операции cmp, и только после выполнения cmp производится проверка "угадали"\"не угадали". Если угадали, то ОК, если нет, то - труба, сливай вода
лин куй с /O1, /O2, /Ox это то что прямо повлияет на кодогенерацию. косвенно, если что-то и влияет - то смотреть самому.. методом пробок и ошибок, но сомневаюсь что что-то еще может влиять кроме этих ключей.
Даже Intel Compiler с грамотным распараллеливанием и оптимизациями не дал на 2-х ядерном проце Intel прироста производительности при компиляции 7Zip. Как я с ключами не мудрил, - добился таки прироста, но он как потом оказалось был "плавающим". Те ключи которые там по дефолту -самые оптимальные по скорости. (в общем качайте исходник и экспериментируйте, там же и тест производительности встроен).
все операции комп проводит хоть наполовину, но над регистрами. и логические и все остальные. те если в then и else проводятся разные операции, но над теми же данными, а для сравнения в ифе регистры пришлось занять совсем иными данными, есть смысл загрузить общее для обоих веток между последним сравнением и первым переходом по условию. любые операции не меняющие флаги допустимы, например можно затолкать в стек одинаковые параметры выбираемых по условию фунок.
