Реалистичное использование ключевого слова C99 «Restrict»?

Я просматривал некоторую документацию и вопросы / ответы и видел упомянутое. Я прочитал краткое описание, в котором говорится, что программист обещает, что указатель не будет использоваться для указания другого места.

Может ли кто-нибудь предложить некоторые реалистичные случаи, когда на самом деле стоит использовать это?

restrictговорит, что указатель - единственная вещь, которая обращается к базовому объекту. Это исключает возможность наложения указателей, обеспечивая лучшую оптимизацию компилятором.

Например, предположим, у меня есть машина со специализированными инструкциями, которая может умножать векторы чисел в памяти, и у меня есть следующий код:

void MultiplyArrays(int* dest, int* src1, int* src2, int n)
{
    for(int i = 0; i < n; i++)
    {
        dest[i] = src1[i]*src2[i];
    }
}

Потребности компилятор правильно обращаться , если dest, src1и src2перекрытия, а это означает , что необходимо выполнить одно умножение в то время, от начала до конца. Имея restrict, компилятор может оптимизировать этот код с помощью векторных инструкций.

В Википедии есть запись restrict, с другим примером, здесь .

Пример Википедии является очень осветительным.

Это ясно показывает, как это позволяет сохранить одну инструкцию по сборке .

Без ограничений:

void f(int *a, int *b, int *x) {
  *a += *x;
  *b += *x;
}

Псевдо сборка:

load R1 ← *x    ; Load the value of x pointer
load R2 ← *a    ; Load the value of a pointer
add R2 += R1    ; Perform Addition
set R2 → *a     ; Update the value of a pointer
; Similarly for b, note that x is loaded twice,
; because x may point to a (a aliased by x) thus 
; the value of x will change when the value of a
; changes.
load R1 ← *x
load R2 ← *b
add R2 += R1
set R2 → *b

С ограничением:

void fr(int *restrict a, int *restrict b, int *restrict x);

Псевдо сборка:

load R1 ← *x
load R2 ← *a
add R2 += R1
set R2 → *a
; Note that x is not reloaded,
; because the compiler knows it is unchanged
; "load R1 ← *x" is no longer needed.
load R2 ← *b
add R2 += R1
set R2 → *b

GCC действительно делает это?

GCC 4.8 Linux x86-64:

gcc -g -std=c99 -O0 -c main.c
objdump -S main.o

С участием -O0 они одинаковы.

С -O3:

void f(int *a, int *b, int *x) {
    *a += *x;
   0:   8b 02                   mov    (%rdx),%eax
   2:   01 07                   add    %eax,(%rdi)
    *b += *x;
   4:   8b 02                   mov    (%rdx),%eax
   6:   01 06                   add    %eax,(%rsi)  

void fr(int *restrict a, int *restrict b, int *restrict x) {
    *a += *x;
  10:   8b 02                   mov    (%rdx),%eax
  12:   01 07                   add    %eax,(%rdi)
    *b += *x;
  14:   01 06                   add    %eax,(%rsi) 

Для непосвященных соглашение о вызовах :

• rdi = первый параметр
• rsi = второй параметр
• rdx = третий параметр

Вывод GCC был даже более ясным, чем статья в вики: 4 инструкции против 3 инструкций.

Массивы

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

Рассмотрим для примера:

void f(char *restrict p1, char *restrict p2) {
    for (int i = 0; i < 50; i++) {
        p1[i] = 4;
        p2[i] = 9;
    }
}

Из-за restrictэтого умный компилятор (или человек) может оптимизировать это так:

memset(p1, 4, 50);
memset(p2, 9, 50);

который потенциально гораздо более эффективен, так как может быть оптимизирован для сборки при достойной реализации libc (например, glibc): лучше ли использовать std :: memcpy () или std :: copy () с точки зрения производительности?

GCC действительно делает это?

GCC 5.2.1. Linux x86-64 Ubuntu 15.10:

gcc -g -std=c99 -O0 -c main.c
objdump -dr main.o

С участием -O0 , оба одинаковы.

С -O3:

• с ограничением:

  3f0:   48 85 d2                test   %rdx,%rdx
  3f3:   74 33                   je     428 <fr+0x38>
  3f5:   55                      push   %rbp
  3f6:   53                      push   %rbx
  3f7:   48 89 f5                mov    %rsi,%rbp
  3fa:   be 04 00 00 00          mov    $0x4,%esi
  3ff:   48 89 d3                mov    %rdx,%rbx
  402:   48 83 ec 08             sub    $0x8,%rsp
  406:   e8 00 00 00 00          callq  40b <fr+0x1b>
                          407: R_X86_64_PC32      memset-0x4
  40b:   48 83 c4 08             add    $0x8,%rsp
  40f:   48 89 da                mov    %rbx,%rdx
  412:   48 89 ef                mov    %rbp,%rdi
  415:   5b                      pop    %rbx
  416:   5d                      pop    %rbp
  417:   be 09 00 00 00          mov    $0x9,%esi
  41c:   e9 00 00 00 00          jmpq   421 <fr+0x31>
                          41d: R_X86_64_PC32      memset-0x4
  421:   0f 1f 80 00 00 00 00    nopl   0x0(%rax)
  428:   f3 c3                   repz retq

  Два memsetзвонка, как и ожидалось.

• без ограничений: никаких вызовов stdlib, просто развертывание цикла в 16 итераций, которое я не собираюсь воспроизводить здесь :-)

У меня не хватило терпения их тестировать, но я считаю, что ограниченная версия будет быстрее.

C99

Давайте посмотрим на стандарт для полноты.

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

Это ограничивает способ вызова функции, но позволяет оптимизировать время компиляции.

Если вызывающая сторона не выполняет restrictдоговор, неопределенное поведение.

Проект C99 N1256 6.7.3 / 7 « Классификаторы типов» гласит:

Предполагаемое использование квалификатора restrict (например, класса хранения регистров) состоит в том, чтобы способствовать оптимизации, и удаление всех экземпляров классификатора из всех блоков предварительной обработки, составляющих соответствующую программу, не меняет его значения (т. Е. Наблюдаемое поведение).

и 6.7.3.1 «Формальное определение ограничения» дает кровные детали.

Строгое правило алиасинга

restrictКлючевое слово влияет только указатели совместимых типов (например , два int*) , поскольку строгие правила наложения спектров говорят , что сглаживание несовместимых типов не определенно поведение по умолчанию, и поэтому компиляторы могут предположить , что это не произойдет и оптимизирует прочь.

Смотрите: что такое строгое правило наложения имен?

Смотрите также

• C ++ 14 еще не имеет аналога для restrict, но GCC имеет __restrict__в качестве расширения: что означает ключевое слово restrict в C ++?
• Много вопросов, которые задают: согласно кровавым деталям, этот код UB или нет?
  • Понимание ограничить классификатор на примерах
  • Вопросы с ограниченным указателем
  • Разрешено ли присваивать ограниченный указатель другому указателю и использовать второй указатель для изменения значения?
• Вопрос «когда использовать»: когда использовать ограничение, а когда нет
• Связанный GCC __attribute__((malloc)), который говорит, что возвращаемое значение функции ни к чему не привязано: GCC: __attribute __ ((malloc))