Presently, `Align()`s are implemented with divisions. This is overcautious: actual memory-related alignments are powers of two and can be handled bitwise; for example, `Align(value, %1000)` is a `(value + %111) and not %111`. `System.Align()` did not have such a restriction and someone could rely on it working with exotic non-PoT alignment, so it must continue to work. But even `System.Align()` will benefit from PoT branch as actual alignments it receives are PoT 100% of the time; on my computer such a branch gives 2× (x86-32) to 5× (x86-64) (1 to 5 ns per call in absolute value) speedup for PoT cases and 10% slowdown for non-PoT that have yet to be spotted in the wild. And internal compiler functions may not be paranoid about non-PoT alignments at all. When compiling my application, compiler calls about half a million of `Align()`s, so saving 2 ns on each is expected to reduce the compilation time by ‌ **o n e ‌ m i l l i s e c o n d!!!** (And the compiler executable size by 2 kb.) [cutils.patch](/uploads/0b37653718430c6d4f458dcc048646ea/cutils.patch) [system.patch](/uploads/7bdf858496f6d18b663c63f4c4cc7e20/system.patch)