Tony Arcieri

> Also note my point about efficiency. observe-based code results in a better codegen. The existing performance problems are already noted in #743. If you replaced `atomic_fence` with this style...

> Well, IIUC even asm! does not provide 100% guarantees here, i.e. a "sufficiently smart" compiler may in theory analyze the asm! block and decide that it can be safely...

> The concept of a "compiler barrier" doesn't really exist, and there's no sound reasoning principle that I am aware of that is based on "compiler barriers" @RalfJung what term...

I still think the best thing we could do with `asm!` is use it to actually implement an optimized memset/bzero routine, where we have guarantees it wouldn't be eliminated, unlike...

I think we only need one implementation of memset/bzero per architecture. The implementation of zeroize itself is already abstracted such that there are two places to actually invoke it from:...

> If by "compiler barrier" you mean "a best-effort heuristic to steer the compiler away from things it shouldn't do", then I have no objections to the term (but I...

> I only see disadvantages when compared to the observation asm!. By using `asm!` to write zeros rather than Rust code, you get actual guarantees those writes will be performed...

Last time I asked about LTO I was told LTO would not touch `asm!`

It’s something I’ve planned on taking a look at after we’ve wrapped up the next release series, unless someone else gets to it first

@fukc-gihtub yes, we should implement a higher-level API using the `password-hash` crate, and that has been on my mental list, but it is a separate issue from this one which...