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 и читать/писать первый байт.

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

Новые блоги и статьи Все статьи Все блоги /
Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .	Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .	У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35". kumehtar 04.08.2026 С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .
Как ИИ начал спорить и врать (возможно почуяв опасность для себя от индустрии - уход от электроники). Hrethgir 04.08.2026 Недельный диалог, на фоне событий с НПЗ. Да, из спирта можно получать бензин, и это не сложно. Но потом в схеме я решил избавиться от насоса, при этом полностью сделав контроль подачи спирта в. . .	Термопринтер QR701 Argus19 03.08.2026 Термопринтер QR701 Купил два термопринтера QR701. На сэлф-тесте написано: Language: PC936 (GB18030). Что означает, что принтеры могут печатать только латиницу и китайские иероглифы. Так же. . .	Создание формы заимствованного документа Maks 03.08.2026 Задача: Необходимо создать собственную форму заимствованного документа. На форме должен быть реквизит "Покупатель", а также табличная часть со следующими реквизитами: - Расчетный счет покупателя. . .	Задача предоставления скидок покупателям Maks 03.08.2026 Задача: В документе "Продажи" необходимо реализовать функционал предоставления скидок покупателям. Скидка должна автоматически рассчитываться и подставляться в соответствующее поле при выборе. . .

Evg 21282 / 8307 / 637 Регистрация: 30.03.2009 Сообщений: 22,669 Записей в блоге: 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