5 ms·

I don't think you would. The list would get unwieldy quick and the order of passes might give you surprising results. It's also possible to get into situations

I don't think you would. The list would get unwieldy quick and the order of passes might give you surprising results. It's also possible to get into situations where your code is incorrect (relies on UB), and just so happens to work with these flags, but not those!

overgard 5y ago
Maybe not, but I feel like as a C programmer I'm already kind of a control freak, and I really want to be able to tell the compiler what I want and where, I don't want magic. I'm using C explicitly because I want to know and control what's going on. If I'm dealing with atomics and concurrent code I really want to tell the compiler, hey, inline constants maybe, but don't reorder or combine operations. Even if the compiler is "right" or my code is subtly wrong, I don't want the compiler making things worse.
- josephcsible 5y ago
  > If I'm dealing with atomics and concurrent code I really want to tell the compiler, hey, inline constants maybe, but don't reorder or combine operations. If that's what you want, then declare your variables volatile (in addition to being atomic, not instead).
  - overgard 5y ago
    At this point I wouldn't expect the compiler to care.
  - astrange 5y ago
    You probably want seq_cst atomics. That's easier to understand and control then volatile is.
    - josephcsible 5y ago
      seq_cst doesn't forbid optimizing `x = 1; x = 2;` into `x = 2;`, though, but volatile does.
      - jcelerier 5y ago
        That doesn't mean that your CPU isn't gonna optimize it anyways afterwards, see for instance all the macro-fusion cases described in here : https://en.wikichip.org/wiki/macro-operation_fusion https://en.wikichip.org/wiki/macro-operation_fusion
        astrange 5y ago
        Atomic instructions wouldn’t be reordered like that on a CPU, that’s the point of using them. Non-atomic ones might be, and volatile would since it’s only a C concept. Although it wouldn’t be through instruction fusion, more like non-coherent caches.
- jcelerier 5y ago
  > but don't reorder or combine operations I hope you're not programming for anything more advanced than a Z80, PIC16F or 6502 then because pretty much any CPU more advanced than that will likely also do that internally. https://en.m.wikipedia.org/wiki/Out-of-order_execution https://en.m.wikipedia.org/wiki/Out-of-order_execution
  - UncleMeat 5y ago
    Yeah. What good is demanding that the assembly has a certain structure if that doesn't mean that the machine actually does it that way? Out of order execution and speculative execution are optimizations that improve performance by 10x or more. They aren't optional.
- pjmlp 5y ago
  Given that 16 bit compilers were already doing that, although in clusmy ways, what you really want is Assembly. Beware that microcoded CPU might still do magic to your beloved Assembly opcodes.

overgard 5y ago

Maybe not, but I feel like as a C programmer I'm already kind of a control freak, and I really want to be able to tell the compiler what I want and where, I don't want magic. I'm using C explicitly because I want to know and control what's going on. If I'm dealing with atomics and concurrent code I really want to tell the compiler, hey, inline constants maybe, but don't reorder or combine operations. Even if the compiler is "right" or my code is subtly wrong, I don't want the compiler making things worse.

josephcsible 5y ago
> If I'm dealing with atomics and concurrent code I really want to tell the compiler, hey, inline constants maybe, but don't reorder or combine operations. If that's what you want, then declare your variables volatile (in addition to being atomic, not instead).
- overgard 5y ago
  At this point I wouldn't expect the compiler to care.
- astrange 5y ago
  You probably want seq_cst atomics. That's easier to understand and control then volatile is.
  - josephcsible 5y ago
    seq_cst doesn't forbid optimizing `x = 1; x = 2;` into `x = 2;`, though, but volatile does.
    - jcelerier 5y ago
      That doesn't mean that your CPU isn't gonna optimize it anyways afterwards, see for instance all the macro-fusion cases described in here : https://en.wikichip.org/wiki/macro-operation_fusion https://en.wikichip.org/wiki/macro-operation_fusion
      - astrange 5y ago
        Atomic instructions wouldn’t be reordered like that on a CPU, that’s the point of using them. Non-atomic ones might be, and volatile would since it’s only a C concept. Although it wouldn’t be through instruction fusion, more like non-coherent caches.
jcelerier 5y ago
> but don't reorder or combine operations I hope you're not programming for anything more advanced than a Z80, PIC16F or 6502 then because pretty much any CPU more advanced than that will likely also do that internally. https://en.m.wikipedia.org/wiki/Out-of-order_execution https://en.m.wikipedia.org/wiki/Out-of-order_execution
- UncleMeat 5y ago
  Yeah. What good is demanding that the assembly has a certain structure if that doesn't mean that the machine actually does it that way? Out of order execution and speculative execution are optimizations that improve performance by 10x or more. They aren't optional.
pjmlp 5y ago
Given that 16 bit compilers were already doing that, although in clusmy ways, what you really want is Assembly. Beware that microcoded CPU might still do magic to your beloved Assembly opcodes.