Является ли ограничение избыточным для константного указателя?

Если мы имеем, например, f и g, определенные как:

void f(const int *restrict a, const int *restrict b, int *c){ ... }
void g(const int *         a, const int *         b, int *c){ ... }

Ассемблирование f и g имеет эквивалентные тела, являются ли они одинаковыми с точки зрения вызывающего?
В вызываемой группе мы можем сделать те же предположения о параметрах?
Есть ли у компилятора те же возможности оптимизации?

Если restrict избыточно, я бы ожидал, что все три ответа будут да. В противном случае, почему бы и нет?

Не принимайте во внимание плохие методы программирования, такие как отбрасывание квалификатора const.

Ответ 1

В этом случае:

void f(const int *restrict a, const int *restrict b, int *c)

restrict не является избыточным. Это означает, что компилятор может предположить, что a и c не являются псевдонимами. Например, если тело функции:

int d = *a;
*c = 5;
d = *a;

тогда компилятор может удалить третью строку.

Это распространяется на C11 6.7.3/7:

Эта связь, определенная в пункте 6.7.3.1 ниже, требует, чтобы все обращения к этот объект прямо или косвенно использует значение этого конкретного указателя.

который говорит, что при доступе к объекту через a, к объекту также не допускается доступ через b или c.

Формальное определение можно увидеть в C11 6.7.3.1/4 (формальное определение ограничения):

Если L используется для доступа к значению объекта X, который он обозначает, и X также изменяется (любым способом), то применяются следующие требования: T не будет const-qual

Здесь T - объявленный тип, на который указывает a, т.е. const int, а L - *a и X есть int, что a и c указывают на.

Ответ 2

Не принимайте во внимание плохие методы программирования, такие как отбрасывание спецификатора const.

Проблема в том, что даже в стандарте C присутствие const в указателе не является обязательным контрактом. Это всего лишь предложение программисту о том, что вызываемый не будет пытаться изменить плацдарм. Фактически, коду разрешено изменять плательщика (после кастинга), если указатель не был первоначально объявлен как объект const.

Поэтому компиляторы не могут безопасно использовать const: им все равно нужно проверить содержимое вызываемого абонента, чтобы убедиться, что он не лежит, если даже возможно.

Ответ 3

Имеет ли компилятор те же возможности оптимизации?

Если я правильно понимаю стандарт, то у компилятора есть большие возможности оптимизации с версией с restrict квалифицированными указателями:

При каждом выполнении B [некоторого блока кода] пусть L будет любое значение l, которое имеет &L на основе P [ограничивающий квалифицированный указатель]. Если L используется для доступа к значению объекта X, который он обозначает, и X также изменяется (любым способом), то применяются следующие требования: T [тип P указывает на] не должен быть const-квалифицированным. [..]

[N1570 §6.7.3.1/4, акцент мой]

Логически говоря, если объект изменен, то указатель на него не должен быть const-квалифицированным. Таким образом, если указатель имеет const-квалификацию, объект не может быть изменен (каким-либо образом).

Xmodified Tconst !Tconst Xmodified -> !Tconst
true      true   false   false // oops, must disallow this case
true      false  true    true
false     true   false   true
false     false  true    true

Таким образом, если компилятор видит T const * restrict, то он может быть уверен, что объект "позади" этого указателя не может быть изменен в течение всего жизненного цикла этого указателя. Как таковой...

Ассемблирование f и g имеет эквивалентные тела, являются ли они одинаковыми с точки зрения вызова?

... это гораздо более надежная гарантия для вызывающего, чем просто использование T const *.