Message-Id: <5246D3E2-E503-40BA-9A72-1876BCF1186B@gmail.com>
Date: Wed, 27 Mar 2024 14:56:13 -0700
From: comex <comexk@...il.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 "Dr. David Alan Gilbert" <dave@...blig.org>,
 Philipp Stanner <pstanner@...hat.com>,
 rust-for-linux <rust-for-linux@...r.kernel.org>,
 linux-kernel@...r.kernel.org,
 linux-arch@...r.kernel.org,
 llvm@...ts.linux.dev,
 Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Wedson Almeida Filho <wedsonaf@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>,
 Andreas Hindborg <a.hindborg@...sung.com>,
 Alice Ryhl <aliceryhl@...gle.com>,
 Alan Stern <stern@...land.harvard.edu>,
 Andrea Parri <parri.andrea@...il.com>,
 Will Deacon <will@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>,
 Nicholas Piggin <npiggin@...il.com>,
 David Howells <dhowells@...hat.com>,
 Jade Alglave <j.alglave@....ac.uk>,
 Luc Maranget <luc.maranget@...ia.fr>,
 "Paul E. McKenney" <paulmck@...nel.org>,
 Akira Yokosawa <akiyks@...il.com>,
 Daniel Lustig <dlustig@...dia.com>,
 Joel Fernandes <joel@...lfernandes.org>,
 Nathan Chancellor <nathan@...nel.org>,
 Nick Desaulniers <ndesaulniers@...gle.com>,
 kent.overstreet@...il.com,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Marco Elver <elver@...gle.com>,
 Mark Rutland <mark.rutland@....com>,
 Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>,
 Catalin Marinas <catalin.marinas@....com>,
 linux-arm-kernel@...ts.infradead.org,
 linux-fsdevel@...r.kernel.org
Subject: Re: [WIP 0/3] Memory model and atomic API in Rust



> On Mar 27, 2024, at 2:21 PM, Boqun Feng <boqun.feng@...il.com> wrote:
> 
> I don't know whether I'm 100% correct on this, but Rust has references,
> so things like "you have a unique reference to a part of memory, no one
> would touch it in the meanwhile" are represented by `&mut`, to get a
> `&mut` from a raw pointer, you need unsafe, where programmers can
> provide the reasoning of the safety of the accesses. More like "pointers
> can alias anyone but references cannot" to me.

Right.  When I said “strict aliasing” I meant type-based aliasing rules, which is what GCC calls “strict aliasing".  But Rust does have stricter aliasing rules than C in a different way.  Both mutable and immutable references are annotated with LLVM `noalias` by default, equivalent to C `restrict`. For mutable references it’s justified because those references should be unique.  For immutable references it's justified because the memory behind the reference shouldn’t be mutated at all.  (There’s an exception for types with ‘interior mutability’, where ‘immutable' references actually can be used for mutation.)

The hope has always been that this gives Rust better overall optimizability than C or C++ and makes up for the losses from the lack of type-based aliasing rules.  If there’s any empirical data to justify or refute this, I’m not aware of it.  But that’s the hope, and by this point Rust is committed to the approach.

(Why only function parameters?  Mainly because of limitations of what LLVM IR can express.  From the perspective of the work-in-progress Rust memory model spec, function parameters are special in *some* ways, but many of the optimizations could apply to all uses of references.  That's just not currently implemented.)

Powered by blists - more mailing lists