3 ms·

The page size is a runtime property - for example recent iOS devices have 16KB pages while older ones are 4k. There may be ways to make it safe, but it seems to

The page size is a runtime property - for example recent iOS devices have 16KB pages while older ones are 4k. There may be ways to make it safe, but it seems to be firmly in the "compiler heroics" camp.

mehrdadn 6y ago
Page sizes are easy to lower bound when you're compiling. You know the target system you're compiling for. This most definitely is not in the "compiler heroics" camp.
- ridiculous_fish 6y ago
  IMO this is one of those fragile optimizations. If the optimization is important, it should be explicit (hand-rolled asm) or else you risk breaking it. If it's not important, then nobody cares. Emitting OoB reads dependent on optimization level? Think about ASAN, debugger watchpoints...can't be worth it! clang has a cool feature that highlights missed vectorization opportunities: > clang++ -O3 -c test.cpp -Rpass-analysis=loop-vectorize test.cpp:5:4: remark: loop not vectorized: loop control flow is not understood by vectorizer [-Rpass-analysis=loop-vectorize] love it!
  - BeeOnRope 6y ago
    In practice this type of over-read is not uncommon in library code (even for standard routines), but I haven't seen compilers generate it. False positives with memory-sanitizers is definitely a problem: the hand-rolled library uses can be whitelisted, but that's not feasible once the compiler starts generating it in arbitrary code.
- cesarb 6y ago
  > Page sizes are easy to lower bound when you're compiling. You know the target system you're compiling for. Do you really know the target system? Most of the time, you want the compiled code to work not only on the current system, but also in future systems of the same lineage. What prevents a future version of the architecture from for instance lowering the translation granule from 4096 bytes to 512 bytes, or even lower?
  - BeeOnRope 6y ago
    This would be a backwards incompatible and massively breaking change on most systems that define a minimum page size. These minimum page sizes are generally treated as or are explicitly architecturally guaranteed.

mehrdadn 6y ago

Page sizes are easy to lower bound when you're compiling. You know the target system you're compiling for. This most definitely is not in the "compiler heroics" camp.

ridiculous_fish 6y ago
IMO this is one of those fragile optimizations. If the optimization is important, it should be explicit (hand-rolled asm) or else you risk breaking it. If it's not important, then nobody cares. Emitting OoB reads dependent on optimization level? Think about ASAN, debugger watchpoints...can't be worth it! clang has a cool feature that highlights missed vectorization opportunities: > clang++ -O3 -c test.cpp -Rpass-analysis=loop-vectorize test.cpp:5:4: remark: loop not vectorized: loop control flow is not understood by vectorizer [-Rpass-analysis=loop-vectorize] love it!
- BeeOnRope 6y ago
  In practice this type of over-read is not uncommon in library code (even for standard routines), but I haven't seen compilers generate it. False positives with memory-sanitizers is definitely a problem: the hand-rolled library uses can be whitelisted, but that's not feasible once the compiler starts generating it in arbitrary code.
cesarb 6y ago
> Page sizes are easy to lower bound when you're compiling. You know the target system you're compiling for. Do you really know the target system? Most of the time, you want the compiled code to work not only on the current system, but also in future systems of the same lineage. What prevents a future version of the architecture from for instance lowering the translation granule from 4096 bytes to 512 bytes, or even lower?
- BeeOnRope 6y ago
  This would be a backwards incompatible and massively breaking change on most systems that define a minimum page size. These minimum page sizes are generally treated as or are explicitly architecturally guaranteed.