Storing pointers unaligned and using memcpy to extract them to an aligned pointer, can be a performance gain, if it means less padding taking up valuable cache space.
GCC always assumes aligned pointer accesses (2020)
21–30 of 128 posts
Re: GCC always assumes aligned pointer accesses (2020)
#22Earlier quoted context omitted.
Because, in some hardware, unaligned read is ok. and you want to take advantage of the hardware feature?
Both gcc and clang will optimize a memcpy to an unaligned load/store where possible.
If the compiler is so smart, I guess it could insert a memcpy when needed?
The standard, you may say.. I would argue it's the standard need to be changed. The modern reading of the standard is not useful as a low-level language and is unsafe as a high-level language.
Re: GCC always assumes aligned pointer accesses (2020)
#23The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…
Honestly, I think you are both incorrect.
C has always had a concept of implementation defined behavior, and unaligned memory accesses used to be defined to work correctly on x86.
Intel added instructions that can’t handle unaligned access, so they broke that contract. I’d argue that it is an instruction set architecture bug.
Alternatively, Intel could argue that compilers shouldn’t emit vector instructions unless they can statically prove the pointer is aligned. That’s not feasible in general for languages like C/C++, so that’s a pretty weak defense of having the processor pay the overhead of supporting unaligned access on some, but not all, paths.
Re: GCC always assumes aligned pointer accesses (2020)
#24The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…
If you really are targeting the x86_64 instruction set, you should be writing x86_64 instructions. Then you get exactly what the hardware does and don’t get any of those pesky compiler assumptions.
Of course you don’t get any of those pleasant optimizations either. But those optimizations are only possible because of the assumptions.
Re: GCC always assumes aligned pointer accesses (2020)
#25The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…
Honestly, I think you are both incorrect. C has always had a concept of implementation defined behavior, and unaligned memory accesses used to be defined to work correctly on x86. Intel added instructions that can’t handle unaligned access, so they broke that contract. I’d argue that it is an instruction set architecture bug. Alternatively, Intel could argue that compilers shouldn’t emit vector instructions unless th…
Unaligned memory accesses are undefined behavior in C. If you're writing C, you should be abiding by C rules. "Used to work correctly" is more guesswork and ignorance than "abiding by C rules". In C, playing fast&loose with definitions hurts, BAD.
Frankly, I'd be ashamed to write this blog post since the only thing it accomplishes is exposing its writers as not understanding the very thing they're signaling expertise on.
Re: GCC always assumes aligned pointer accesses (2020)
#26In a project I'm working on[0], there's an array object type used throughout, which can sometimes point to arbitrary data elsewhere. In a funky edge-case[1], such an array can be built with an unaligned data pointer.
Thus, if gcc/clang started seriously utilizing aligned pointer accesses everywhere, nearly every single load & store in the entire project would have to be replaced with something significantly more verbose. Maybe in a more fancy language you could have ptr vs unaligned_ptr or similar, but in C you kinda just have compiler flags, and maybe __attribute__-s if you can spare some verbosity.
C UB is often genuinely useful, but imo having an opt-out option for certain things is, regardless, a very reasonable request.
[0]: https://github.com/dzaima/CBQN
[1]: Any regularly allocated array has appropriate alignment. But there are some functions that take a slice of the array "virtually" (i.e. pointing to it instead of copying), and another one that bitwise-reinterprets an array to one with a different element type (again, operating virtually). This leads to a problem when e.g. taking i8 elements [3;7) and reinterpreting as an i32 array. A workaround would be to make the reinterpret copy memory if necessary (and this would have to be done if targeting something without unaligned load/store), but that'd ruin it being a nice O(1).
Re: GCC always assumes aligned pointer accesses (2020)
#27Machine language architecture is flawed. The assumption of alignment is in the machine language.
Compilers can only use the instructions that are there. They have a difficult choice: close their eyes and generate aligned-pointer moves, or use a sequence of tests and partial move instructions that is orders of magnitude less efficient.
We've needed machine instructions to load or move memory efficiently regardless of alignment, for decades.
Re: GCC always assumes aligned pointer accesses (2020)
#28The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…
That's what the author meant when he said "The shift of the C language from “portable assembly” to “high-level programming language without the safety of high-level programming languages”" Back in the 1980s, C was expected to do what hardware does. There was no "the C abstract machine". The abstract machine idea was introduced much later. > The arguments in this blogpost are fundamentally flawed. The "fundamentally f…
To the best of my recollection the “abstract machine” is a C++ism that unfortunately crept into C.
Re: GCC always assumes aligned pointer accesses (2020)
#29Earlier quoted context omitted.
This line in particular really bugs me: > The present blog post brings bad, and as far as I know, previously undocumented news. Even if you really are targeting an instruction set without any memory access instruction that requires alignment, GCC still applies some sophisticated optimizations that assume aligned pointers. I could have told you this was true ~20 years ago, and the main reason I'm so conservative in ho…
It dates to the first standardization of C in 1989. The "C as portable assembly" view ended when ANSI C got standardized, and K&R's 2nd edition was published.
For C to be portable this needs to be undefined behaviour because there are CPUs that don’t support unaligned access