Per VognsenFeb 23
Saw this when randomly flipping through the code base of something posted to Lobsters. C or C++ is not the language for you if you think you can write code like that. https://c.godbolt.org/z/8q5zoh6Ke
Compiler Explorer - C (x86-64 gcc 15.2)

// https://github.com/abdimoallim/jit typedef int32_t i32; typedef uint8_t u8; typedef size_t usz; typedef struct { u8* buf; usz len; } jit_buf; void jit_ensure(jit_buf* j, usz n) {} // bad void jit_emit_i32(jit_buf* j, i32 v) { jit_ensure(j, 4); j->buf[j->len + 0] = (u8)(v); j->buf[j->len + 1] = (u8)(v >> 8); j->buf[j->len + 2] = (u8)(v >> 16); j->buf[j->len + 3] = (u8)(v >> 24); j->len += 4; } // good void jit_emit_i32_fixed(jit_buf* j, i32 v) { jit_ensure(j, 4); u8* buf = j->buf; usz len = j->len; buf[len + 0] = (u8)(v); buf[len + 1] = (u8)(v >> 8); buf[len + 2] = (u8)(v >> 16); buf[len + 3] = (u8)(v >> 24); j->len = len + 4; } int main() {}

Show threadPer Vognsen
There's a certain systems language with pervasive noalias guarantees where you can write code like that but C is assuredly not that language.
Feb 23 at 4:50amPhanpy
Show threadArseny KapoulkineFeb 23
@pervognsen eh in that language every [] is a branch so it’s not magically better
Show threadJonathan MüllerFeb 23
@zeux @pervognsen You can use get_unchecked.
Show threadArseny KapoulkineFeb 23
@foonathan @pervognsen In both cases, the generated code for naive version is suboptimal and changing the code to get optimal codegen isn’t too hard.
Show threadSean BarrettFeb 24
@pervognsen Isn't this one of the cases that strict aliasing optimizations are supposed to enable?
Show threadPer VognsenFeb 24
@nothings Not in this case. A store via a char pointer is expressly allowed to alias any type.
Show threadSean BarrettFeb 24
@pervognsen Oh right, of course. For some reason the page loaded with the struct scrolled off the top so I didn't see the types, and I didn't really look close enough to notice the casts.
Show threadMarc B. ReynoldsFeb 24

@pervognsen @nothings Both GCC & clang produce the desired if 'restrict' is added to the jit_buf pointer. That seems "wrong" to me.

https://c.godbolt.org/z/6sGsh7xnY

Compiler Explorer - C

// https://github.com/abdimoallim/jit typedef int32_t i32; typedef uint8_t u8; typedef size_t usz; typedef struct { u8* buf; usz len; } jit_buf; void jit_ensure(jit_buf*j, usz n) {} // bad void jit_emit_i32(jit_buf* j, i32 v) { jit_ensure(j, 4); j->buf[j->len + 0] = (u8)(v); j->buf[j->len + 1] = (u8)(v >> 8); j->buf[j->len + 2] = (u8)(v >> 16); j->buf[j->len + 3] = (u8)(v >> 24); j->len += 4; } // seems wrong to me void jit_emit_i32_humm(jit_buf* restrict j, i32 v) { jit_ensure(j, 4); j->buf[j->len + 0] = (u8)(v); j->buf[j->len + 1] = (u8)(v >> 8); j->buf[j->len + 2] = (u8)(v >> 16); j->buf[j->len + 3] = (u8)(v >> 24); j->len += 4; } // good void jit_emit_i32_fixed(jit_buf* j, i32 v) { jit_ensure(j, 4); u8* buf = j->buf; usz len = j->len; buf[len + 0] = (u8)(v); buf[len + 1] = (u8)(v >> 8); buf[len + 2] = (u8)(v >> 16); buf[len + 3] = (u8)(v >> 24); j->len = len + 4; } int main() {}

Show threadPer VognsenFeb 24
@mbr @nothings No? That's as expected.
Show threadAlexander MonakovFeb 24
@pervognsen @mbr
I'm not sure what can look suspicious here
Show threadMarc B. ReynoldsFeb 24
@amonakov @pervognsen It's my brain today that's suspicious.
Show threadSean BarrettFeb 24
@pervognsen @mbr The char pointer inside the struct "inherits" the restrict qualifier from the pointer to the struct? I didn't realize that (I think I've never actually used restrict.)
Show threadPaul KhuongFeb 24
@nothings @pervognsen @mbr the char buf doesn't alias with the struct because the pointer to the struct is restricted.
Show threadSean BarrettFeb 24
@pkhuong @pervognsen Ah right, of course, that makes sense. Thanks!
Show threadPer VognsenFeb 24
@nothings @mbr No, that's not exactly how it works. It's declaring that this jit_buf *restrict j pointer (and anything derived from it) is the only way to access the pointee object in this scope (and it's UB if you then violate that). "Derived" means things like (j+1)-1, &j->buf, &j->len, but not a pointer like j->buf which just happens to be the value of a field in j. So, this 'restrict' example would optimize just as well if you pass in char *buf as a separate param to the function.
Show threadPer VognsenFeb 24
@nothings @mbr But yeah, it's what Paul said, I'm just trying to clarify why the j->buf pointer isn't considered derived from j in the way that &j->buf is when it comes to aliasing.
Show threadPer VognsenFeb 24
@nothings @mbr FWIW, despite the fact that 'restrict' has been in C since C99, after rustc started actually relying on LLVM's implementation of 'noalias' (which is what 'restrict' is compiled down to with clang) it took literally years of fixing the long tail of LLVM bugs due to the fact that approximately no-one uses it in C.
Show threadWolf480plFeb 24
@pervognsen
@nothings @mbr
I think a couple years ago, restrict started appearing all over glibc manpages - could this be related?
Show threadPer VognsenFeb 24
@wolf480pl @nothings @mbr Dunno. I'm curious how bug-free gcc's implementation of 'restrict' will turn out to be. Until rustc_codegen_gcc is further along I doubt we'll know for sure. I think the experience with LLVM suggests that there aren't enough C use cases in the wild to flush out bugs via C compilers.
Show threadAntonio PatriarcaFeb 24
@pervognsen @nothings @mbr I think this is also partially related to C++ not supporting it and thus AFAIK C library headers using it are not compatible with C++
Show threadAndre WeissflogFeb 24
@antopatriarca @pervognsen @nothings @mbr tbf, most libraries would wrap the restrict in a macro with a compiler specific keyword. Some popular C compiler feature not being standardized never was a showstopper ;)