Hacker News Reader

> It won't be erroneously optimizing entire loops to some random constant anymore. One would think they'd emit a warning instead in these cases but no.

It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

> This is C. We do things like write memory allocators. Of course we're going to alias stuff. I have a structure type, I have a byte buffer with the data, of course I want to overlay the type on the byte buffer and just access it directly. Why is it that the compiler just doesn't let me reinterpret memory however I want? Compiler has no business making my life hell because of this.

char is allowed to alias other types. Other types of aliasing are rarely needed and you can always memcpy the contents if you really do need to.

> Turns out the C standard prescribes some "strict aliasing" nonsense because Fortran has it or some other reason nobody really cares about. If you're doing anything at all in C you're probably violating this.

No prescribes it because otherwise it would need to load from memory on every pointer dereference after something completely different has been written to. This is obviously undesirable if you care even one bit about performance.

None of these things are the compiler fighting you. In fact it is trying to help you. But you seem to want something closer to high-level assmebler and you can have that: don't use and optimizing compiler or use flags to change the language semantics to your taste. That doesn't make the default semantics bad though.

> I have no idea what the performance impact is and honestly I don't care.

Then C and C++ are simply not made for you. There are plenty of "safe" languages for people who don't care about the perfomance impact.

> If anyone here knows of any other useful flags that define the undefined, please reply to this comment. I'll add them to my makefiles without thinking twice.

Try -O0.

> It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

Hmm, could possibly include optimization flags directly into the source code (would be clearer and less compiler mess perhaps). I could also see this causing other issues...

Most compilers have (non-standard) constructs to control optimizations

> It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

Yeah. That's sad but there's nothing that can be done about it. If you write C you're basically guaranteed to violate strict aliasing at some point and I just cannot handle the uncertainty anymore. The Linux kernel developers are much smarter than me and as far as I know they reached the same conclusion as I did: this aliasing stuff is not even worth enabling.

I know there's a may_alias attribute you can apply to pointers to warn the compiler but I'm not confident in my ability to do it 100% correctly. I have a feeling it'd end up getting applied to a significant chunk of the code anyway, might as well just turn it off.

> char is allowed to alias other types.

I know. But can uint8_t? It's basically the same type as unsigned char but it's still a distinct type in the compiler's eyes. Never found a definitive answer to that question. What if you define your own u8 type?

I know for a fact uint16_t can't safely alias anything. Implementing a 16 bit hash function? Hoping to just treat an arbitrary buffer as an array of u16? Not gonna happen unless you turn off this aliasing nonsense.

> Other types of aliasing are rarely needed and you can always memcpy the contents if you really do need to.

I shouldn't have to copy huge buffers all over the place just to get the compiler to generate the simple instructions I want. This is on the same level as the "pointer laundering" advice I've received. Oh just pass the pointer through some inline assembly, compiler can't see into it so it assumes anything can happen and it won't screw up the code trying to optimize. This memcpy is just yet another thing the compiler can't see into. The proper solution is to kill the problematic optimizations.

> No prescribes it because otherwise it would need to load from memory on every pointer dereference after something completely different has been written to. This is obviously undesirable if you care even one bit about performance.

It doesn't have to be that way. I statically link all my code, enable link time optimization, pass flags like -fwhole-program. Surely the compiler can analyze the entire program and statically determine that certain pointers do not alias.

I have a memory allocator that works with a huge statically allocated byte buffer as its backing memory. Surely the compiler can determine that all pointers returned by my memory allocation functions are subsets of that buffer and that they do not necessarily alias each other.

> use flags to change the language semantics to your taste

That's exactly what I was advocating for in my post.

> That doesn't make the default semantics bad though.

I would argue that they are extremely bad. Compilers will straight up delete overflow and null checks from your code if the conditions are right. This can cause it to "optimize" entire functions into literally nothing. There's just no way anyone can convince me that this is not adversarial, if not malicious.

> Then C and C++ are simply not made for you.

C was made to support the development of Unix. I'm writing similar low level Linux operating system stuff. I'd say I'm closer to the target audience than all these speed obsessed folks ever were.

> There are plenty of "safe" languages for people who don't care about the perfomance impact.

I absolutely do care about performance in general.

I said I don't care about the performance impact of that one flag. Adding that flag buys me the certainty that the compiler won't screw the code up based on absolute nonsense assumptions that I don't ever want it to make. I've made the decision to not care in this case. I absolutely do want all the other optimizations the C compilers will give me.

And I don't want "safe", I want "sane".

Things like signed integer overflow not being C's particularly idiotic "can't ever happen, please delete any checks" flavor of undefined falls under my definition of "sane". I also consider overlaying a structure on top of a byte buffer to be such a basic operation there's no point in using C at all if the compiler is gonna screw this up.

> Try -O0.

No. That disables too many useful optimizations that are not problematic in any way whatsoever.

> I have no idea what the performance impact is and honestly I don't care.

Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

Perhaps you use C because you must interact with other C code; many languages have quite usable C FFI. If you must use C because your code is part of another project (e.g. the Linux kernel), you don't have control over the flags anyway. If you must use C because of low memory availability (e.g. a microcontroller), then perhaps fine — but that's quite niche. (And there's always Rust.)

C was hardly a performance juggernaut in the 1980's, any junior Assembly coder could easily outperform the outcome of the C compilers.

It was by exploring UB to the extreme those compilers optimizers do nowadays, that such language finally got the fame it has 40 years later.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

The 21st century renaissance of high level languages got us somewhat back on track.

> C was hardly a performance juggernaut in the 1980's, any junior Assembly coder could easily outperform the outcome of the C compilers.

I think that's not especially relevant. The issue is that most other higher level programming languages had poorer performance and/or inserted undesirable mysteriously-timed lags in performance. Fortran had excellent performance, but Fortran at that time couldn't handle many constructs that C can. Some Common Lisp implementations at the time had reasonable performance, but the garbage collectors often inserted pauses (ugh!), and many were expensive at the time too.

Also: The 1980s was the rise of the IBM PC-compatible (and the Macs too). These were machines whose underlying chips matched C decently well (they had hardware-implemented large stacks unlike the 6502), however, these machines were underpowered compared to what some people wanted them to do. This also had a rise in Unix servers, where C was their native tongue.

> Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

This goal seems somewhat oxymoronic - if the "goal" is to be keenly aware of what the compiler will do and double check all assembly, then you shouldnt use C. If the goal is to ignore assembly and not pay attention to these sorts of things, then you shouldnt use C.

The only valid niche I see is where the goal is to use C, not really have to worry about the assembly, have it do the "right" thing on your platform. I.e. no undefined behavior, just underperforming (and called out as such). Then you can go in and "approve" various optimizations.

> Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

If performance is your top priority C is also the wrong choice.

What would you suggest instead?

If you are writing general purpose software, I would suggest Rust if I have nothing else to go on, although there are plenty of other good choices if you know more about the problem.

In a few cases there is today a special purpose language for the kind of thing you're writing which will knock both C and Rust on their backs for performance because it was never trying to do anything else.

I think C is still a good choice for the following reasons: - Performance is generally very good and while special languages can sometimes be better it usually easily possible to get the C code to the same level. - But with special languages you will often run into limitations where you are stuck. - It has long term stability - Compile-times are short which I really like - There are good tools - It has very good interoperability with everything - The code an easily be reused from most other languages, so it does not tie you into a specific framework - etc..

I write C because I like C. That's the only reason I've got. It's what I feel comfortable writing code in. I tried learning Rust but I just couldn't get used to it.

I like C where I write the functions and the structures and the compiler just translates it to the simple processor instructions you expect it to. No complicated hidden machinery under the hood, just simple unmangled symbols pointing at simple code that conforms to simple ABIs. This simplicity is also the reason the so called "C ABI" is so ubiquitous.

Another reason I write C is it's one of very few languages with freestanding code support. I only write freestanding C targeting the Linux kernel-userspace ABI. In my opinion C is a much nicer language without the libc and its legacy. I really enjoy it.

It’s been a long time since I worked with C, but my recollection was that a) strict aliasing allows for optimizations that are actually worthwhile, and b) it’s really easy to type pun in a defined way using unions anyway.

> strict aliasing allows for optimizations that are actually worthwhile

I don't think there are many sensible, real world examples.

A nice explanation of the optimizations the strict-aliasing rule allows: https://stackoverflow.com/a/99010/66088

The example given is:

    typedef struct Msg {
        unsigned int a;
        unsigned int b;
    } Msg;

    void SendWord(uint32_t);

    int main(void) {
        // Get a 32-bit buffer from the system
        uint32_t* buff = malloc(sizeof(Msg));

        // Alias that buffer through message
        Msg* msg = (Msg*)(buff);

        // Send a bunch of messages
        for (int i = 0; i < 10; ++i) {
            msg->a = i;
            msg->b = i+1;
            SendWord(buff[0]);
            SendWord(buff[1]);
        }
    }

The explanation is: with strict aliasing the compiler doesn't have to think about inserting instructions to reload the contents of buff every iteration of the loop.

The problem I have is that when we re-write the example to use a union, the generated code is the same regardless of whether we pass -fno-strict-aliasing or not. So this isn't a working example of an optimization enabled by strict aliasing. It makes no difference whether I build it with clang or gcc, for x86-64 or arm7. I don't think I did it wrong. We still have a memory load instruction in the loop. See https://godbolt.org/z/9xzq87d1r

Knowing whether a C compiler will make an optimization or not is all but impossible. The simplest and most reliable solution in this case is to do the loop hoisting optimization manually:

        uint32_t buff0 = buff[0];
        unit32_t buff1 = buff[1];
        for (int i = 0; i < 10; ++i) {
            msg->a = i;
            msg->b = i+1;
            SendWord(buff0);
            SendWord(buff1);
        }

Doing so removes the load instruction from the loop. See https://godbolt.org/z/ecGrvb3se

Note 1: The first thing that goes wrong for Stackoverflow example is that the compiler spots that malloc returns uninitialized data, so it can omit the reloading of buff in the loop anyway. In fact it removes the malloc too. Here's clang 18 doing that https://godbolt.org/z/97a8K73ss. I had to replace malloc with an undefined GetBuff() function, so the compiler couldn't assume the returned data was unintialized.

Note 2: Once we're calling GetBuff() instead of malloc(), the compiler has to assume that SendWord(buff[0]) could change buff, and therefore it has to reload it in the loop even with strict-aliasing enabled.

How does the version with buf0 and buf1 work? It looks like it sends always the same two values...

Hmmm, yes. I didn't understand what the code did.

Instead of creating those buff0 and buff1 variables before the loop, I should have done:

    for (int i = 0; i < 10; ++i) {
        unsigned a = i;
        unsigned b = i+1;
        msg->a = a;
        msg->b = b;
        SendWord(a);
        SendWord(b);   
    }

That gets rid of the load from the loop. https://godbolt.org/z/xsqWfxKzd

The strict aliasing stuff allows you to do "optimisations" across translation units that are otherwise unsound.

The compiler alias analysis is much more effective than those rules permit within a translation unit because it matters whether int* alias other int*.

And then we have link time optimisation, at which point the much better alias analysis runs across the whole program.

What remains therefore is a language semantically compromised to help primitive compilers that no longer exist to emit slightly better code.

This is a deeply annoying state of affairs.

Aliasing analysis is quite helpful for sophisticated compilers to generate good code.

Alias analysis is critical. Knowing what loads and stores can alias one another is a prerequisite for reordering them, hoisting operations out of loops and so forth. Therefore the compiler needs to do that work - but it needs to do it on values that are the same type as each other, not only on types that happen to differ.

Knowing that different types don't alias is a fast path in the analysis or a crutch for a lack of link time optimisation. The price is being unable to write code that does things like initialise an array using normal stores and then operates on it with atomic operations, implement some floating point operations, access network packets as structs, mmap hashtables from disk into C structs and so forth. An especially irritating one is the hostility to arrays that are sometimes a sequence of simd types and sometimes a sequence of uint64_ts.

Though C++ is slowly accumulating enough escape hatches to work around that (launder et al), C is distinctly lacking in the same.

Alias analysis is important. It's the C standard's type-based "strict aliasing" rules which are nonsense and should be disabled by default.

This is C. Here in these lands, we do things like cast float* to int* so that we can do evil bit level manipulation. The compiler is just gonna have to put that in its pipeline and compile it.

The optimizations can easily be gained back by "manual" loading and storing to temporary local variables.

The classical:

  int foo(float *f, int *x) {
    *x = 2;
    *f = 3.0f;
    return *x; // oh no, without typed based aliasing I have to load x again!
  }

Can obviously be rewritten to:

  int foo(float *f, int *x) {
    int z = 2;
    *x = z;
    *f = 3.0f;
    return z; // ah, thank you programmer, z has not had its address taken, it's obviously 2.
  }

That code does not violate the aliasing rules in any case.

The two functions you wrote are not the same; the first re-reads *x which may return a different value than 2 if *x was modified in between the first and third lines of the function by another thread (or hardware). However, since x is not marked volatile, the compiler will usually optimize the first function to behave the same as the second.

Type punning with unions was actually forbidden by C89. You were only ever supposed to read the union member which was last written to. This may have been relaxed in C17; I can only find a draft online, but it allows for type punning in unions as long as the member being read is not longer in size than the member last written to.

IIRC it was supported in C89 and described as implementation-defined and C99 changed the wording and mentions union type punning.

What the standard says doesn't really matter. Only what major compilers do matters. GCC has decreed that type punning through unions is supported, therefore it might as well be standard.

>> Pretty much every computer that matters works the way you expect it to: the value will overflow, some flag will be set, etc. The compiler couldn't care less though.

And RISC-V drops the hardware flags entirely. I questioned this when I read it, but "carry" is really only useful in asm code for adding and subtracting integers larger than register size, which is not much of a thing these days. None of the flags are accessible from C either so they just dropped them and things seem to be going well!

> but "carry" is really only useful in asm code for adding and subtracting integers larger than register size, which is not much of a thing these days

Funny you mention that. I'm studying math and algorithms to implement the arbitrary precision integer support for my programming language. The word "carry" is showing up a lot in my research so that bit does seem to be an incredibly useful feature and I have no idea why they'd remove it.

> None of the flags are accessible from C either so they just dropped them and things seem to be going well!

I know you can't directly access those flags but the fact is compilers do provide their functionality to programmers via builtins.

For example:

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

Those builtins will cause the compiler to generate optimal instructions such as conditional jumps that depend on the carry or overflow bits.

I used the __builtin_mul_overflow function to check for overflow in my memory allocation code.

This is what we really want. We want to handle these conditions, no matter how they're implemented. This is a perfectly acceptable way for the compiler to expose these processor features in a way that makes sense to us programmers. In the case of RISC-V, GCC will just emit whatever code is appropriate for checking overflows on that processor.

What's definitely not acceptable is for the compiler to just go "aw man look at this USELESS overflow checking code over here, AS WE ALL KNOW signed integer overflow is UNDEFINED and therefore CANNOT EVER HAPPEN, why the hell is this shit for brains programmer checking for a thing that can't happen, I'll just go ahead delete this nonsense code literally right now, oh wow would you look at that, looks like I just optimized the entire program into a noop, I must be the best compiler in the universe".

> Pretty much every computer that matters works the way you expect it to

Except the ones that saturate, that produce trap values, etc.