Strict aliasing и memcpy

@Renji · Регистрация: 05.06.2014

Студворк — интернет-сервис помощи студентам

Что-то я никак не врублюсь, как согласуются между собой strict aliasing и функции жонглирующие void*? Возьмем для примера memcpy. Стандартная оптимизация данной функции - копировать данные не отдельными байтами, а кусками побольше. Например, int-ами. Но для этого надо залезть через int* указатель в данные, которые вообще говоря могут и не являться массивом int. А strict aliasing такие фокусы запрещает. Однако, функция в стандарте есть. Так как она тогда в этот стандарт вписывается?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
void*myMemcpy(void*dst,const void*src,std::size_t size)
{
    int*dstInt=reinterpret_cast<int*>(dst);
    const int*srcInt=reinterpret_cast<const int*>(src);
    for(;size>=sizeof(int);size-=sizeof(int))
        //строго следуя букве стандарта, здесь у нас UB
        //ведь никто не сказал что по адресу srcInt действительно лежит int
        *dstInt++=*srcInt++;
 
    char*dstChar=reinterpret_cast<char*>(dstInt);
    const char*srcChar=reinterpret_cast<const char*>(srcInt);
    for(;size;--size)
        *dstChar++=*srcChar++;
    return dst;
}

Ну и выдержка из стандарта:
If a program attempts to access the stored value of an object through a glvalue of other than one of the
following types the behavior is undefined: 52
— the dynamic type of the object,
— a cv-qualified version of the dynamic type of the object,
— a type similar (as defined in 4.4) to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type
of the object,
— an aggregate or union type that includes one of the aforementioned types among its elements or non-
static data members (including, recursively, an element or non-static data member of a subaggregate
or contained union),
— a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
— a char or unsigned char type.

@Renji · 09.06.2017, 12:56 **[ТС]**

Сообщение от IGPIGP

Я смогу относиться к strict aliasing с пониманием, только когда увижу адекватный код, в котором такая оптимизация уместна. Если у кого-то есть примеры, -покажите пожалуйста.

C++
1
2
3
++*a;//в момент инкремента, копия *a уезжает в регистр
*b=1;//возможно, здесь изменили и *a за компанию
return*a;//поэтому здесь *a придется читать заново, а не взять значение из регистра

И решается эта проблема давно уже придуманным в Си ключевым словом restrict ("данные по этому указателю ни с чем не пересекаются, инфа - соточка"). Только его никак в стандарт плюсов не перетащат.

IGPIGP · 09.06.2017, 13:11

Сообщение от Renji

И решается эта проблема давно уже придуманным в Си ключевым словом restrict ("данные по этому указателю ни с чем не пересекаются, инфа - соточка"). Только его никак в стандарт плюсов не перетащат.

Тут вообще не понял. Если b указатель на a и имеет его тип (из текста не видно) то данный код совершенно корректен. strict aliasing запрещает писать по указателю на другой тип но по тому же адресу без возможных проблем.
В Вашем коде этого не видно. Всё вроде нормально. Если компилятор и тут имеет право, что-то не сделать, то осталось совсем немного до дурдома. Или я не прав?

@TRam_ · 09.06.2017, 13:34

Сообщение от IGPIGP

Если компилятор и тут имеет право, что-то не сделать

Имеет право, если a и b указывают на одну и ту же область памяти. Компилятор посчитает, что ему незачем обращаться к памяти по адресу a повторно, если у него *a и так лежит в регистре. Вот только память-то изменялась в *b=1. То есть рассинхронизация того что в регистре и того что в памяти.

@Renji · 09.06.2017, 13:44 **[ТС]**

Сообщение от IGPIGP

Тут вообще не понял. Если b указатель на a и имеет его тип (из текста не видно) то данный код совершенно корректен. strict aliasing запрещает писать по указателю на другой тип но по тому же адресу без возможных проблем.

Если указатель a и b имеют разный тип, скорее всего запись в *b не влияет на *a. Но без strict aliasing такое предположить нельзя, а значит после *b=1 нужно перечитывать *a.

IGPIGP · 09.06.2017, 14:42

Сообщение от TRam_

Компилятор посчитает, что ему незачем обращаться к памяти по адресу a повторно, если у него *a и так лежит в регистре.

Хм... Но это же не обращение к одной и той же памяти по указателям разного типа. Это использование указателя по прямому назначению. Тут же если то что Вы говорите принять как аргумент, вообще нельзя будет работать с указателями и даже ссылками. То есть нельзя будет ссылаться на одну и ту же память из разных переменных.
Я читая того же Аксёнова понял, что именно различные по типу указатели на одну и ту же память могут быть разыменованы для записи без разыменования и записи. Дико это. И поэтому я попросил пример, который бы показывал, когда адекватный код, может быть ускорен такой оптимизацией без риска навредить тому кто такой код написал. То есть я хочу понять мотивы разрабов компиляторов.

Сообщение от Renji

Если указатель a и b имеют разный тип, скорее всего запись в *b не влияет на *a.

Почему? Если в коде указано напрямую, что есть обращение на запись?
Покажите мне пример, когда программист написал такое, для того чтобы оно было оптимизировано и не выполнено. Иначе создаётся впечатление, что авторы шепчут ( а в сишечке такого и нету, может туда лучше вернуться? ). Шучу.

Evg · 09.06.2017, 15:16

Чисто на всякий случай: restrict и strict-aliasing - это немного перпендикулярные вещи.

Strict-aliasing - это то, что исторически было раньше. Возможно, что исходили из того, что в реальной жизни указатели на разные типы данных в реальной жизни в 99.99% случаев не пересекаются. Поэтому нужно было что-то изобрести, чтобы компилятор в коде:

C
float *p1;
int *p2;
...
*p1 = ...
... = *p2;

мог переставить местами операцию чтения из памяти и операцию запись в память. Зачем это нужно я в своё время описывал тут: [Задача] Адресная арифметика. Вероятно, strict-aliasing и было тем изобретением, которое в большом количестве случаев позволяло load'ы перенести выше store'ов. Но со временем, вероятно, этого уже стало мало, а потому появились restrict'ы, как подсказка со стороны программиста, что два указателя смотрят на заведомо не пересекающиеся участки памяти. И всё это с той же самой целью - переставить load'ы как можно выше по исполнению, потому что во многих случаях это даёт приличный привар к скорости исполнения

@rat0r · 09.05.2018, 17:41

Сообщение от Renji

Интерпретировать источник как массив char шибко накладно по времени.

Да и некорректно.

Сообщение от TheCalligrapher

Во-первых, концептуально, функции типа memcpy переинтерпретируют исходные объекты, как массивы unsigned char. Это прямо разрешено правилами strict aliasing.

Есть мнение, что правила strict aliasing разрешают только кастить к указателю на (unsigned) char и читать/писать первый байт.
Арифметика указателей при этом не разрешена, т.к. этот указатель не указывает на элемент массива из (unsigned) char.

@Renji · 09.05.2018, 23:37 **[ТС]**

Сообщение от rat0r

Есть мнение, что правила strict aliasing разрешают только кастить к указателю на (unsigned) char и читать/писать первый байт.

Тогда бы получилось что либо реализация std::istream::read злостно нарушает стандарт, либо что из файлов можно читать только char-ы.

Croessmah · 09.05.2018, 23:44

Сообщение от Renji

std::istream::read злостно нарушает стандарт

Библиотечные штуки могут делать что угодно без всяких нарушений.

@rat0r · 10.05.2018, 00:14

Сообщение от Renji

Тогда бы получилось что либо реализация std::istream::read злостно нарушает стандарт

std::istream::read ничего сама не нарушает.
А вот программист может нарушить неправильным её использованием.

Сообщение от http://eel.is/c++draft/input.streams#istream.unformatted-itemdecl:12

basic_istream<charT, traits>& read(char_type* s, streamsize n);
Effects: Behaves as an unformatted input function (as described above). After constructing a sentry object, if !good() calls setstate(failbit) which may throw an exception, and return. Otherwise extracts characters and stores them into successive locations of an array whose first element is designated by s.

Отсюда можно сделать вывод, что в read можно совать только массив из символов и что указатель должен указывать на первый элемент массива.

@Renji · 10.05.2018, 00:40 **[ТС]**

Сообщение от Croessmah

Библиотечные штуки могут делать что угодно без всяких нарушений.

Вот только библиотечные штуки - просто обертка над std::streambuf::xsgetn, который быть библиотечным никому не обязан (перегруженная виртуальная функция).

Сообщение от rat0r

Отсюда можно сделать вывод, что в read можно совать только массив из символов и что указатель должен указывать на первый элемент массива.

Ну так и как прикажете читать из файла POD-объекты отличные от массива символов? Если никак, то зачем там тогда у файловых потоков бинарный режим чтения?

@rat0r · 11.05.2018, 15:39

Сообщение от Renji

Ну так и как прикажете читать из файла POD-объекты отличные от массива символов?

А откуда в файлах вообще взялись объекты?

Сообщение от Renji

Если никак, то зачем там тогда у файловых потоков бинарный режим чтения?

Из стандарта C (т.к. стандарт C++ говорит, что binary mode соответствует модификатору "b" в stdio):

Сообщение от 7.21.2/3

A binary stream is an ordered sequence of characters that can transparently record
internal data. Data read in from a binary stream shall compare equal to the data that were
earlier written out to that stream, under the same implementation. Such a stream may,
however, hav e an implementation-defined number of null characters appended to the end
of the stream.

Вот за этим.

@Renji · 11.05.2018, 19:11 **[ТС]**

Сообщение от rat0r

А откуда в файлах вообще взялись объекты?

Из оператора присваивания бессовестно примененного к отображенному в память файлу. Ах да, отображение файла в память, видимо, тоже нарушает стандарт.

Croessmah · 11.05.2018, 19:24

Сообщение от Renji

Ах да, отображение файла в память

В C++ нет такого.

Сообщение от Renji

тоже нарушает стандарт

Операционная система (и иже с ней) и компиляторы предоставляют определенные гарантии.
Им вообще пофиг на этот стандарт. У них свои правила.

@Renji · 11.05.2018, 19:41 **[ТС]**

Сообщение от Croessmah

Операционная система (и иже с ней) и компиляторы предоставляют определенные гарантии.

Компилятор про отображение файлов ничего не знает, для него это самая обычная не инициализированная память. Навигация в которой разумеется осуществляется через адресную арифметику с char*. Ну не указатели же в файле хранить, они при повторном отображении станут невалидны. Вот только rat0r адресную арифметику с char* считает нарушением strict aliasing, так что получается что пользователи отображения файлов в память стандарт злостно нарушают.

Croessmah · 11.05.2018, 20:15

Сообщение от Renji

Вот только rat0r адресную арифметику с char* считает нарушением strict aliasing

Он вообще не про strict aliasing. И для char*, как выше уже говорили - исключение в плане strict aliasing.

@rat0r · 22.05.2018, 04:32

Сообщение от rat0r

Есть мнение, что правила strict aliasing разрешают только кастить к указателю на (unsigned) char и читать/писать первый байт.

Или я соврал. Даже чтение первого байта не гарантировано.
В общем, муть.

Новые блоги и статьи Все статьи Все блоги /
Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))
Как у меня протекала болезнь zorxor 27.08.2026 Здравствуйте, друзья! Эта запись блога предназначена именно для вас - для моих дорогих друзей, которые знали меня лично. Чтобы ответить на вопрос - а что же со мной произошло на самом деле? Я учился. . .	Нашел вот забавное видео о измерениях. Лучшее что я видел на эту тему kumehtar 26.08.2026 ILETXiw9bMQ Основная суть и тезисы по измерениям: 0D (Нулевое измерение): точка, не имеющая длины, ширины, высоты или объема. Объект не может перемещаться в 0D. 1D (Первое измерение):. . .	[EasyBuilder Pro] Памятка по разработке для панелей Weintek ФедосеевПавел 26.08.2026 Памятка по разработке для панелей Weintek ВВЕДЕНИЕ Ранее, при реализации проектов основное внимание уделял разработке управляющей программы для контроллера, а панели оператора доставалось время. . .	Модель по догадкам anaschu 25.08.2026 Прошло две недели. Я уже рассказывал, как разговаривал с сотрудниками у сортировки и как понял, что главная ветка — не про приёмку, а про отбор. Но тогда я думал, что понял механику. На этой неделе я. . .

Evg 21285 / 8310 / 637 Регистрация: 30.03.2009 Сообщений: 22,671 Записей в блоге: 30
	09.06.2017, 15:16
	Чисто на всякий случай: restrict и strict-aliasing - это немного перпендикулярные вещи. Strict-aliasing - это то, что исторически было раньше. Возможно, что исходили из того, что в реальной жизни указатели на разные типы данных в реальной жизни в 99.99% случаев не пересекаются. Поэтому нужно было что-то изобрести, чтобы компилятор в коде: C float p1; int p2; ... p1 = ... ... = p2; мог переставить местами операцию чтения из памяти и операцию запись в память. Зачем это нужно я в своё время описывал тут: [Задача] Адресная арифметика. Вероятно, strict-aliasing и было тем изобретением, которое в большом количестве случаев позволяло load'ы перенести выше store'ов. Но со временем, вероятно, этого уже стало мало, а потому появились restrict'ы, как подсказка со стороны программиста, что два указателя смотрят на заведомо не пересекающиеся участки памяти. И всё это с той же самой целью - переставить load'ы как можно выше по исполнению, потому что во многих случаях это даёт приличный привар к скорости исполнения 2