Здравствуйте, Eeel, Вы писали:

E>Ну мне надо, например, параллельно сложить нижнее и верхнее 32-битные слова (нижнее с нижним, верхнее с верхним), так, чтобы при сложении нижнего не было переноса в верхнее. Но потом использовать это все как одно 64-битное слово.

Ну, например

a + b - (1<<32)&((a+b)^~(a^b))

И пусть себе там компилятор разбирается, как оптимизировать?
Ещё всякие векторные инструкции для этого рулят...

E>Просто не хочется слепо надеяться на оптимизатор и писать заведомо бессмысленные битовые операции. Профессиональным подходом здесь было бы сделать бенчмарк, пожалуй, и именно так я и сделаю в итоге.
Его надо делать на всех платформах... Стоит ли выигрыш затрат?

E>Меня просто еще интересует концептуальная возможность обходить strict aliasing rule, так как оно является очень большим ограничением.
Оно нужно для того, что бы развязать руки оптимизатору. Обходя его, ты неизбежно свободу оптимизатора снизишь (или код будет непредсказуемо работать)

E>Ну отмена переносимости кода мало помогает, так как сама по себе не отменяет правила strict aliasing в компиляторах. А от опций и версий конкретных компиляторов не хочется зависеть.
Если бы тебе нужна была именно работа с битиками памяти, например в конце стояло бы устройство отображённое на память, то как раз от опций компилятора ты бы тогда не зависел. Возможно, твой код в разных случаях интерпретировал бы ОДНИ И ТЕ ЖЕ битики по ОДНИМ И ТЕМ ЖЕ адресам, как разные числа, но когда дело доходило бы до аппаратных битиков, всё было бы правильно.

А тебе таки нужны числа, а не аппаратные битики. Вот с числами и работай. Так ндёжно, а обходить — мешать оптимизатору.
Иногда оптимизаторы лажают, конечно, но редко. И там, под конкретный оптимизатор, если задача очень нагруженная, можно сделать отдельную ветку кода, завязанную на особенности конкретного транслятора в конкретных настройках. Только это никак со strict aliasing rule не связано, оптимизаторы могут лажать сотнями способов...

E>

E>Еще у меня была мысль про буфер char'ов: по стандарту любой тип можно алиазить массивом чаров, тогда что если записать этот в массив std::uint64_t, а прочитать два std::uint32_t — будет ли это нарушением strict aliasing rule? Очевидный ответ — да, поскольку читается один тип, а записывается другой. А может и нет. Этот момент мне неясен.

Очевидный ответ верный. Просто сравни поведение на двух системах, где разный эндиан, и сразу поймёшь, что это так и есть...
Кроме того, при таком подходе ещё и проблемы с выравниванием добавятся...