Телеграмм чат группы compilerdev страница 723

а ллвм-у достаточно одного

13:09пожаловаться #1

звучит логичнее у гцц

13:09пожаловаться #2

почитал про рестрикт

13:11пожаловаться #3

всё стало понятно

13:11пожаловаться #4

что-то мои знания С99 весьма печальны

13:11пожаловаться #5

EgorBo

звучит логичнее у гцц

дыа

13:24пожаловаться #6

пушо может оверлапнуть

13:25пожаловаться #7

Berkus Decker

пушо может оверлапнуть

какая-то опасная оптимизация тогда, юзер намеренно выбрал безопасный memmove а тут привет

13:26пожаловаться #8

EgorBo

какая-то опасная оптимизация тогда, юзер намеренно выбрал безопасный memmove а тут привет

думаю llvm еще дополнительный анализ проводит что у второго пойнтера тоже имплицитный restrict

13:27пожаловаться #9

то есть инлайнит и потом проверяет что на входе таки не оверлапящиеся указатели

13:28пожаловаться #10

Berkus Decker

думаю llvm еще дополнительный анализ проводит что у второго пойнтера тоже имплицитный restrict

нихрена

13:28пожаловаться #11

ну ка

13:28пожаловаться #12

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

13:29пожаловаться #13

причём любой указатель

13:29пожаловаться #14

а не только рестрикт

13:29пожаловаться #15

то есть одного рестрикта должно быть достаточно

13:29пожаловаться #16

https://godbolt.org/z/beVeuB

godbolt.org

Compiler Explorer - LLVM IR (llc (trunk))

define void @test(i8* noalias, i8*, i32) {
%4 = sext i32 %2 to i64
call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 %0, i8* align 1 %1, i64 %4, i1 false)
ret void
}

declare void @llvm.memcpy.p0i8.p0i8.i64(i8*, i8*, i64, i1 immarg)

13:29пожаловаться #17

я прав?

13:30пожаловаться #18

llvm ir ^

13:30пожаловаться #19

void test(char* restrict a, char* b, int len)
{
memmove(a,b,len);
}

int main() {
char a[100];
char b[100];
test(a, b, 100);
test(a, b, 50);
test(a, a, 100);
print(a, 100);
print(b, 100);
}

EgorBo

llvm ir ^

https://godbolt.org/z/ggkDxx вообще не вызывает твой memcpy )

godbolt.org

Compiler Explorer - C