Достаточно ли ограничить только параметры «out» (указателя) функции?

Ключевое слово const, как показано, вызовет предупреждение или ошибку, если вы попытаетесь изменить значение, на которое указывает указатель, но оно не обязательно помешает вам изменить это значение, и уж точно не помешает кому-то другому изменить это значение. Таким образом, компилятору, возможно, придется предположить, что такие изменения могут иметь место.

Например, если вы вызываете некоторую функцию, определенную в другом исходном файле, компилятор не будет знать, что делает эта функция, поэтому ему придется предположить, что функция каким-то образом может иметь доступ к значению, указанному этим указателем, и может измените его.

Более того, даже если вы измените значение, на которое указывает неконстантный указатель, этот неконстантный указатель может указывать на то же значение, что и константный указатель. (Например, f( &x, &x );) Без restrict в указателе const компилятор должен предполагать, что это тоже возможно.

Таким образом, даже параметр const может выиграть от ключевого слова restrict, поскольку оно обещает, что память, на которую указывает этот указатель, не будет никем изменена. По сути, вы обещаете, что никогда не будете делать что-то вроде f( &x, &x );.

Нет, этого недостаточно.

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

Это предположение недостаточно. Также было бы необходимо, чтобы компилятор видел, что функция иначе не записывает в память, на которую указывает указатель (включая любую память, к которой можно получить доступ через указатель, например b[18]). Например, если вызывается bar(b);, а компилятор не видит bar, то он не может знать, изменяется ли память, на которую указывает b, во время выполнения f, даже если это не так.

Дайте эту дополнительную предпосылку, что компилятор может видеть, что нет никаких изменений в любой памяти, на которую указывает b, тогда для оптимизации не имеет значения, объявлен ли b с помощью const и/или restrict: компилятор знает все о памяти и сообщает это ничего больше информации не добавляет.

Однако зачастую код не удовлетворяет этому предположению. (И даже если это так, программисту может быть неприятно быть в этом уверенным.) Итак, давайте рассмотрим случай, когда у нас нет дополнительной посылки:

void f(int * restrict a, int const *b)
{
    printf("%d\n", *b);
    bar();
    printf("%d\n", *b);
}

Когда вызывается bar, компилятор не знает, изменен ли *b. Несмотря на то, что эта функция не передает b в bar, bar может получить доступ к некоторому внешнему объекту, который является *b или имеет указатель на то, где находится *b, и поэтому bar может изменить объект, который является *b. Поэтому компилятор должен перезагрузить *b из памяти для второго printf.

Если вместо этого мы объявим функцию void f(int * restrict a, int const * restrict b), то restrict утверждает, что если *b изменяется во время выполнения f (в том числе косвенно, внутри bar), то каждый доступ к ней будет осуществляться через b (напрямую, как в *b, или косвенно, как через указатель, явно скопированный или вычисленный из b). Поскольку компилятор видит bar не получает b, он знает, что bar не содержит никаких обращений к *b, основанных на b, и поэтому может предположить, что bar не изменяется *b.

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

Предположим, у меня есть функция, которая принимает некоторые параметры указателя - некоторые неконстантный, с помощью которого он может писать, и некоторый константный, с помощью которого он может только читает. Пример:

void f(int * a, int const *b);

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

Теперь достаточно ли этого (согласно стандарту языка C) для достижения преимущества restrict для всех прочтений в пределах f(), только для restrict выходные параметры? то есть в примере ограничить a, но не b?

restrict односторонний. Он разрешает компилятору делать предположения о доступе к объекту через lvalue, «основанные» на restrict-квалифицированном указателе, которые не зависят от того, является ли какой-либо другой указатель также restrict-квалифицированным.

В частности, если вы restrict параметр a, то независимо от того, используете ли вы также restrict параметр b, вы разрешаете компилятору предполагать, что во время любого выполнения f(),

• если L — любое lvalue, адрес которого «основан на» a, и
• L используется для доступа к объекту, который он обозначает (чтение или запись), и
• этот объект каким-либо образом изменяется во время выполнения функции, затем
• каждый доступ к этому объекту (чтение или запись) во время выполнения этой функции будет осуществляться через lvalue, адрес которого «основан на» a, хотя и не обязательно именно через L.
• (Например, к этому объекту нельзя будет получить доступ через значение lvalue «на основе» b, но не на a.)

Более подробно это изложено в разделе 6.7.3.1 C17, хотя этот текст одновременно сложен и немного перегружен.

Таким образом, в описанном вами случае restrictтолько a дает компилятору право предполагать, что чтение с помощью указателей, полученных из b, никогда не будет наблюдать за записью с помощью указателей, полученных из a. Разумеется, будет ли он на самом деле генерировать другой код — это совершенно другой вопрос.