News for hackers. Stuff that matters.

A comment on Translating Quake 3 into Rust. Parent comment

Re:Translating Quake 3 into Rust by vintermann on Tuesday January 07, 2020 @12:11PM (#21981955)
There are some "shoulds" related to aliasing I believe. Things the compiler can assume when compiling a rust program that it can't when compiling C, which should in theory let it generate more efficient code.

But last I heard Rust wasn't taking advantage of this due to issues with LLVM. The same benefits should also be achievable in C with pragmas.

[ Parent | on HN ]
Re:Translating Quake 3 into Rust by masklinn on Tuesday January 07, 2020 @02:32PM (#21983780)
> There are some "shoulds" related to aliasing I believe.

c2rust has to be careful not to "restrict" pointers which can in fact alias.

> But last I heard Rust wasn't taking advantage of this due to issues with LLVM.

That's correct: https://github.com/rust-lang/rust/issues/54878

> The same benefits should also be achievable in C with pragmas.

I don't know that any compiler provides a noalias-all pragma. I don't know that it would be very sane either since C very much defines pointers as aliasing by default. Plus you wouldn't have any way to revert this behaviour and mark pointers as aliasing.

[ Parent | on HN ]
Re:Translating Quake 3 into Rust by jashmatthews on Tuesday January 07, 2020 @06:06PM (#21986224)
> C very much defines pointers as aliasing by default.

This is actually a huge issue for the CRuby JIT which generates C from the VM bytecode. Alias analysis on the generated C code, which is full of indirection, is basically useless and severely restricts the possible optimizations.

[ Parent | on HN ]