3 ms·

I've found the lack of alias guarantees to be far more bark than bite. What's the primary use case? For automatic vectorization? Ultimately the only cost to che

by kolbe 3y ago

I've found the lack of alias guarantees to be far more bark than bite. What's the primary use case? For automatic vectorization? Ultimately the only cost to check is an integer add and an integer comparison. Yeah, aliasing guarantees would eliminate those two ops (and eliminate generating the aliased version's code path). But in general, it isn't some 8x monumental cost that many people think it is.

einpoklum 3y ago
> What's the primary use case? For automatic vectorization? No. Without aliasing guarantees, every load via a by-ref/by-addr input param after a store via another such param must actually be executed. So either you manually cache your accesses, or you can't do loop unrolling, strength reductions, and possibly other optimization work. > Ultimately the only cost to check is an integer add and an integer comparison 1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do. 2. The interest is also for the _definition_ side of things, not just for the implementation. I want to tell the user of my function "pass unaliased arguments". This is important, because otherwise you have to provide a bunch of convoluted implementations for the case of there _being_ aliasing - which often changes the semantics of the function to something you had no intention of writing. 3. In real life, there is no guarantee that memory ranges with disjoint addresses are not aliases of the same region. There's probably no such guarantee that the standard makes, but IANALL.
- kolbe 3y ago
  Sorry I didn't see your response. > 1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do. I wasn't implying to do it manually. Compilers do it all the time. 2, I understand and would use. I also want to restrict input alignment. 3, I never knew, but compilers I use for x86 on linux seem to think it's fine to just check memory address distances.

by kolbe 3y ago

einpoklum 3y ago

> What's the primary use case? For automatic vectorization? No. Without aliasing guarantees, every load via a by-ref/by-addr input param after a store via another such param must actually be executed. So either you manually cache your accesses, or you can't do loop unrolling, strength reductions, and possibly other optimization work. > Ultimately the only cost to check is an integer add and an integer comparison 1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do. 2. The interest is also for the _definition_ side of things, not just for the implementation. I want to tell the user of my function "pass unaliased arguments". This is important, because otherwise you have to provide a bunch of convoluted implementations for the case of there _being_ aliasing - which often changes the semantics of the function to something you had no intention of writing. 3. In real life, there is no guarantee that memory ranges with disjoint addresses are not aliases of the same region. There's probably no such guarantee that the standard makes, but IANALL.

kolbe 3y ago
Sorry I didn't see your response. > 1. Manually checking that will likely not affect the compiler. Again, you can implement your own optimizations, but that's not what you want to do. I wasn't implying to do it manually. Compilers do it all the time. 2, I understand and would use. I also want to restrict input alignment. 3, I never knew, but compilers I use for x86 on linux seem to think it's fine to just check memory address distances.