tweaks

diff --git a/personal/_posts/2019-07-14-uninit.md b/personal/_posts/2019-07-14-uninit.md
index dd71945750070c242bda06954a8f858db03a28d5..e2089cb9ca09f42d97db73203f6ca40bc78e24f5 100644 (file)
--- a/personal/_posts/2019-07-14-uninit.md
+++ b/personal/_posts/2019-07-14-uninit.md
@@ -121,9 +121,9 @@ But when writing Rust programs, even when writing Rust programs that you only in
 The Rust abstract machine *does* make a distinction between "relaxed" and "release"/"acquire", and your program will go wrong if you ignore that fact.
 After all, x86 does not have "uninitialized bytes" either, and still our example program above went wrong.
 
 The Rust abstract machine *does* make a distinction between "relaxed" and "release"/"acquire", and your program will go wrong if you ignore that fact.
 After all, x86 does not have "uninitialized bytes" either, and still our example program above went wrong.
 

-Of course, desirable optimizations explain *why* the abstract machine is defined the way it is.
+Of course, to explain *why* the abstract machine is defined the way it is, we have to look at optimizations and hardware-level concerns.

 But without an abstract machine, it is very hard to ensure that all the optimizations a compiler performs are consistent---in fact, both [LLVM](https://bugs.llvm.org/show_bug.cgi?id=35229) and [GCC](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752) suffer from miscompilations caused by combining optimizations that all seem fine in isolation, but together cause incorrect code generation.
 But without an abstract machine, it is very hard to ensure that all the optimizations a compiler performs are consistent---in fact, both [LLVM](https://bugs.llvm.org/show_bug.cgi?id=35229) and [GCC](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752) suffer from miscompilations caused by combining optimizations that all seem fine in isolation, but together cause incorrect code generation.

-The abstract machine is the ultimate arbiter that shows if all of the optimizations are correct, or if some of them are in conflict with each other.
+The abstract machine is needed as an ultimate arbiter that shows if all of the optimizations are correct, or if some of them are in conflict with each other.

 I also think that when writing unsafe code, it is much easier to keep in your head a fixed abstract machine as opposed to a set of optimizations that might change any time, and might or might not be applied in any order.
 
 Unfortunately, in my opinion not enough of the discussion around undefined behavior in Rust/C/C++ is focused on what concretely the "abstract machine" of these languages looks like.
 I also think that when writing unsafe code, it is much easier to keep in your head a fixed abstract machine as opposed to a set of optimizations that might change any time, and might or might not be applied in any order.
 
 Unfortunately, in my opinion not enough of the discussion around undefined behavior in Rust/C/C++ is focused on what concretely the "abstract machine" of these languages looks like.