Re: Type-based alias analysis and Gecko C++
On Wed, Feb 27, 2019 at 10:20 AM Henri Sivonen wrote: > Given the replies to this thread and especially the one I quoted > above, I suggest appending the following paragraph after the first > paragraph of > https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code I've made the edit after checking with Ehsan. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
On Tue, Feb 19, 2019 at 10:17 PM Gabriele Svelto wrote: > On the reverse I've seen performance regressions from using > -fno-strict-aliasing only in tight loops where the inability to move > accesses around was lengthening the critical path through the loop. > However this was on processors with very limited memory reordering > capabilities; my guess is that on today's hardware > -fno-strict-aliasing's impact is lost in the noise. Given the replies to this thread and especially the one I quoted above, I suggest appending the following paragraph after the first paragraph of https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code : On the side of extending C++, we compile with -fno-strict-aliasing. This means that when reinterpreting a pointer as a differently-typed pointer, you don't need to adhere to the "effective type" (of the pointee) rule from the standard when dereferencing the reinterpreted pointer. You still need make sure that you don't violate alignment requirements and need to make sure that the data at the memory location pointed to forms a valid value when interpreted according to the type of the pointer when dereferencing the pointer for reading. Likewise, if you write by dereferencing the reinterpreted pointer and the originally-typed pointer might still be dereferenced for reading, you need to make sure that the values you write are valid according to the original type. This issue is moot for e.g. primitive integers for which all bit patterns of their size are valid value. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
On Fri, Feb 22, 2019 at 1:00 AM Jeff Walden wrote:
>
> On 2/17/19 11:40 PM, Henri Sivonen wrote:
> > Rust, which combines the
> > perf benefits of -fstrict-aliasing with the understandability of
> > -fno-strict-aliasing?
>
> This is not really true of Rust. Rust's memory model is not really defined
> yet https://doc.rust-lang.org/reference/memory-model.html but from what I've
> been able to read as to how you're "supposed" to and "should" use the
> language in unsafe code and through FFI, it *does* require the same sorts of
> things as C++ in "you can't dereference a pointer/reference unless it
> contains a well-formed value of the type of the pointer/reference". Just,
> Rust has somewhat more tools that hide away this unsafety so you don't often
> manually bash on memory yourself in that manner.
Requiring a dereferenced pointer to point to a value that is
well-formed according to the type of the pointer is *very* different
from having requirements on how the value was written ("effective
type"). E.g. all possible bit patterns of f64 are well-formed bit
patterns for u64, so in Rust it's permissible to use a u64-typed
pointer to access a value that was created as f64. However, in C++
(without -fno-strict-aliasing, of course), if the "effective type" of
a pointee is double, i.e. it was written as double, it's not
permissible to access the value via a uint64_t-type pointer.
In fact, the Rust standard library even provides an API for such viewing:
https://doc.rust-lang.org/std/primitive.slice.html#method.align_to
The unsafety remark is not in terms of aliasing but in terms of
*value* transmutability. The method is fully safe when U is a type for
which all bit patterns of U's size are valid values. (I'm a bit
disappointed that there isn't a safe method to that effect with a
trait bound to a trait that says that all bit patterns are valid. Then
primitive integers and SIMD vectors of integer lanes could implement
that marker trait.)
> As a practical matter, I don't honestly see how Rust can avoid having a
> memory model very similar to C++'s, including with respect to aliasing, even
> if they're not there *formally* yet.
As far as I'm aware, Ralf Jung, who is working on the formalization,
is against introducing *type-based* alias analysis to Rust. Unsafe
Rust has informal and will have formal aliasing rules, but all
indications are that they won't be *type-based*.
See
https://www.ralfj.de/blog/2018/08/07/stacked-borrows.html
https://www.ralfj.de/blog/2018/11/16/stacked-borrows-implementation.html
https://www.ralfj.de/blog/2018/12/26/stacked-borrows-barriers.html
for the aliasing rule formulation that does not involve type-based
alias analysis.
--
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
On 2/17/19 11:40 PM, Henri Sivonen wrote: > Rust, which combines the > perf benefits of -fstrict-aliasing with the understandability of > -fno-strict-aliasing? This is not really true of Rust. Rust's memory model is not really defined yet https://doc.rust-lang.org/reference/memory-model.html but from what I've been able to read as to how you're "supposed" to and "should" use the language in unsafe code and through FFI, it *does* require the same sorts of things as C++ in "you can't dereference a pointer/reference unless it contains a well-formed value of the type of the pointer/reference". Just, Rust has somewhat more tools that hide away this unsafety so you don't often manually bash on memory yourself in that manner. As a practical matter, I don't honestly see how Rust can avoid having a memory model very similar to C++'s, including with respect to aliasing, even if they're not there *formally* yet. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
Adding my 2p On 19/02/19 17:54, Jason Orendorff wrote: >> My understanding is that the original purpose is that if you in a loop >> read from T* and write on each iteration via U* (where T and U differ >> by more than signedness and neither is char), without >> -fno-strict-aliasing the compiler doesn't need to pessimize on the >> assumption that a write via U* might change the next read via T*. With >> -fno-strict-aliasing, the compiler has to pessimize on the assumption >> that a write via U* might affect the next read via T*. The problem is >> that if accessing a T-typed value via U* is UB *in general*, who knows >> what *else* the compiler might do if -fno-strict-aliasing is not used >> and there are reinterpret_casts between pointer types, especially with >> LTO giving it a broader view to spot UB. The most common issue I ran into when not using -fno-strict-aliasing on code with strict aliasing violations is that at high optimization levels the compiler reordered the memory accesses to the pointers that it assumed were not aliasing each other. Depending on the code and the types involved this can result in anything between an immediate (but confusing) crash or subtle data-corruption bugs. On the reverse I've seen performance regressions from using -fno-strict-aliasing only in tight loops where the inability to move accesses around was lengthening the critical path through the loop. However this was on processors with very limited memory reordering capabilities; my guess is that on today's hardware -fno-strict-aliasing's impact is lost in the noise. Gabriele signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
I accidentally sent a question to Henri only. Re-adding the list. -j On Mon, Feb 18, 2019 at 1:24 AM Henri Sivonen wrote: > On Fri, Feb 15, 2019 at 6:27 PM Jason Orendorff > wrote: > > > > On Fri, Feb 15, 2019 at 3:00 AM Henri Sivonen > wrote: > >> > >> If we have no intention of getting rid of -fno-strict-aliasing, it > >> would make sense to document this at > >> > https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code > >> and make it explicitly OK for Gecko developers not to worry about > >> type-based alias analysis UB--just like we don't worry about writing > >> exception-safe code. > > > > > > Not worrying about exceptions is easy for me to understand: I can assume > that exceptions are never thrown. > > > > What does it mean to not worry about type-based alias analysis UB? > > (This needs a big "as I understand it" disclaimer from me:) > > It means that it's OK to reinterpret_cast T* into U* even if T and U > differ by more than signedness and neither T nor U is char (or signed > char or unsigned char). > > > What kind of code is OK under -fno-strict-aliasing, > > E.g. code that views a buffer of doubles via uint64_t* (without a > memcpy in between). Or code that casts char16_t* to wchar_t* in clang > on Windows. (MSVC doesn't implement type-based alias analysis anyway.) > > More importantly in terms of usage frequency but less importantly in > terms of what C++ implementations we actually use, viewing a buffer of > uint8_t via a pointer to some other type or vice versa. (Whether > uint8_t is the same as unsigned char and, therefore, whether uint8_t* > can alias anything, or whether uint8_t is a non-char type of the same > size that doesn't inherit char's aliasing rules is > implementation-defined. So whether something is Undefined Behavior is > implementation-defined behavior. AFAIK, in the implementations we > actually use, uint8_t is unsigned char. See > https://bugzilla.mozilla.org/show_bug.cgi?id=1426909#c21 and > https://bugzilla.mozilla.org/show_bug.cgi?id=1426909#c30 .) > > > and what does it do? > > My understanding is that the original purpose is that if you in a loop > read from T* and write on each iteration via U* (where T and U differ > by more than signedness and neither is char), without > -fno-strict-aliasing the compiler doesn't need to pessimize on the > assumption that a write via U* might change the next read via T*. With > -fno-strict-aliasing, the compiler has to pessimize on the assumption > that a write via U* might affect the next read via T*. The problem is > that if accessing a T-typed value via U* is UB *in general*, who knows > what *else* the compiler might do if -fno-strict-aliasing is not used > and there are reinterpret_casts between pointer types, especially with > LTO giving it a broader view to spot UB. > > The unproductivity is being afraid of reinterpret_cast on pointers due > to not knowing what it might let the compiler do and whatever > counter-measures and debates arise from not knowing. With > -fno-strict-aliasing, reinterpret_cast on pointers works in a way that > programmers can reason about. > > As for whether the optimizations enabled by the absence of > -fno-strict-aliasing are valuable: On one hand, MSVC doesn't have the > optimizations to begin with (AFAIK). On the other hand, they perceived > as so valuable that a notable component of the motivation of char8_t > is to make it a separate aliasing domain from char. Similarly, C++ > already makes char16_t and char32_t distinct aliasing domains from > uint16_t and uint32_t while C does not. (So compiling C code that does > not have UB in C++ mode can make the code have UB if > -fno-strict-aliasing is not in use.) > > [...] > > -- > Henri Sivonen > hsivo...@mozilla.com > -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
On 2/17/2019 11:40 PM, Henri Sivonen wrote: Out of curiosity: Do we know if WebKit and Chromium compile with or without strict-aliasing? Chromium disabled strict aliasing in 2010 [1] and then in 2013 WONTFIX'd the bug that would re-enable strict aliasing[2]. The WONTFIX discussion [3] reported no big performance improvements (on Dromaeo or Octane) and cited Firefox bug comments with similar results (for SunSpider and V8 benchmarks). The Firefox test used gcc 4.3 in 2011. Maybe strict aliasing optimizations are better with clang in 2019? [1] https://chromium.googlesource.com/chromium/src/+/ecf52cb820c80a600436aca1a5a72533db32b48d [2] https://bugs.chromium.org/p/chromium/issues/detail?id=32204 [3] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/dUebWSEpAR8/xhsispuiNu4J ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
On Fri, Feb 15, 2019 at 6:47 PM Ted Mielczarek wrote: > > On Fri, Feb 15, 2019, at 4:00 AM, Henri Sivonen wrote: > > How committed are we to -fno-strict-aliasing? > > FWIW, some work was done to investigate re-enabling strict aliasing a while > ago but it proved untenable at the time: > https://bugzilla.mozilla.org/show_bug.cgi?id=414641 The bug was closed with "Realistically, this is WONTFIX. Life is too short to figure out why -O3 breaks -fstrict-aliasing." That conclusion makes sense to me. Is there any reason to believe that strict-aliasing in clang would yield the kind of performance benefits that would outweigh the trouble of writing strict-aliasing-conformant code and the performance penalties of additional memcpy() required for strict-aliasing-conformant code? Out of curiosity: Do we know if WebKit and Chromium compile with or without strict-aliasing? On Fri, Feb 15, 2019 at 4:43 PM David Major wrote: > If we can easily remove (or reduce) uses of this flag, I think > that would be pretty uncontroversial. What are the UB implications of using it for some parts of the code but not for others in the context of LTO? If we have specific places where we'd need strict-aliasing for performance, shouldn't we write those bits in Rust, which combines the perf benefits of -fstrict-aliasing with the understandability of -fno-strict-aliasing? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
On Fri, Feb 15, 2019, at 4:00 AM, Henri Sivonen wrote: > How committed are we to -fno-strict-aliasing? FWIW, some work was done to investigate re-enabling strict aliasing a while ago but it proved untenable at the time: https://bugzilla.mozilla.org/show_bug.cgi?id=414641 -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
On Fri, Feb 15, 2019 at 8:43 AM David Major wrote: > [...] If we can easily remove (or reduce) uses of this flag, I think > that would be pretty uncontroversial. > It sounds risky to me. My impression is we have a lot of TBAA violations, which would make every compiler version bump a game of UB roulette, right? Probably looks like I'm weighing in on both sides here. I'm saying the situation is not ideal. -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Type-based alias analysis and Gecko C++
I don't think anyone wants to allow aliasing merely for its own sake. A lot of these flags were added just to keep builds working in the face of noisy compilers a long time ago. It would be good to retest with our current codebase and current compilers and see where we stand. If we can easily remove (or reduce) uses of this flag, I think that would be pretty uncontroversial. But if it turns out to be a huge amount of work, then as nice as it would be to do the cleanup, it might not be a justifiable use of time and opportunity cost. On Fri, Feb 15, 2019 at 3:59 AM Henri Sivonen wrote: > > I happened to have a reason to run our build system under strace, and > I noticed that we pass -fno-strict-aliasing to clang. > > How committed are we to -fno-strict-aliasing? > > If we have no intention of getting rid of -fno-strict-aliasing, it > would make sense to document this at > https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code > and make it explicitly OK for Gecko developers not to worry about > type-based alias analysis UB--just like we don't worry about writing > exception-safe code. > > Debating in design/review or making an effort to avoid type-based > alias analysis UB is not a good use of time if we're committed to not > having type-based alias analysis. > > -- > Henri Sivonen > hsivo...@mozilla.com > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
