5 ms·

I'd love to have a compiler that just tells me what optimizations could be made, but let me either do it myself (if syntactically available in the language), or

I'd love to have a compiler that just tells me what optimizations could be made, but let me either do it myself (if syntactically available in the language), or explicitly mark the optimization as ok through a #pragma or something like that. I just think having to read the disassembly to figure out what happened isn't a great user experience.

tjalfi 5y ago
SGI compilers had diagnostic information called love notes that explains what optimizations had been applied to loops. Here is an example taken from [0]. #<loop> Loop body line 1, nesting depth: 1, estimated iterations: 17 #<loop> Unrolled 2 times #<swps> Pipelined loop line 1 steady state #<swps> 50 estimated iterations before pipelining 2 unrollings before pipelining #<swps> 6 cycles per 2 iterations #<swps> 4 flops #<swps> ( 33% of peak) (madds count as 2) #<swps> ( 16% of peak) (madds count as 1) ( 33% of peak) #<swps> 2 flops #<swps> 2 madds #<swps> 6 mem refs #<swps> 3 integer ops ( 25% of peak) #<swps> 11 instructions ( 45% of peak) 1 short trip threshold #<swps> 5 integer registers used. #<swps> 9 float registers used. [0] https://cug.org/5-publications/proceedings_attendee_lists/2002CD/S02_Proceedings/Pages/Authors/Cellis.pdf https://cug.org/5-publications/proceedings_attendee_lists/20...
- ndesaulniers 5y ago
  These are called remarks in GCC and clang and are controlled by -R family of flags.
ndesaulniers 5y ago
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
mhh__ 5y ago
Doesn't do exactly what you want, but try -fopt-info-all in GCC. Gives you a reasonably informative guide of what it tried to do and whether it used the transformation or not.
- overgard 5y ago
  Thanks! I'll try that.
UncleMeat 5y ago
This would be fun, and it can be made available from the major compilers, but using it almost certainly bad for most developers. Any nonstandard decisions you make here are likely to be unstable. Even if they are better for one build, they will sit in a config file and rot to the point that you've sabotaged your future performance by making decisions for an older build. I see this all the time with nonstandard flags for performance. Somebody five years ago had a problem with the VM and needed to change the way GC worked and set a flag. Nobody remembers why and they are all afraid to touch it. Now the application is getting worse performance.

tjalfi 5y ago

SGI compilers had diagnostic information called love notes that explains what optimizations had been applied to loops. Here is an example taken from [0]. #<loop> Loop body line 1, nesting depth: 1, estimated iterations: 17 #<loop> Unrolled 2 times #<swps> Pipelined loop line 1 steady state #<swps> 50 estimated iterations before pipelining 2 unrollings before pipelining #<swps> 6 cycles per 2 iterations #<swps> 4 flops #<swps> ( 33% of peak) (madds count as 2) #<swps> ( 16% of peak) (madds count as 1) ( 33% of peak) #<swps> 2 flops #<swps> 2 madds #<swps> 6 mem refs #<swps> 3 integer ops ( 25% of peak) #<swps> 11 instructions ( 45% of peak) 1 short trip threshold #<swps> 5 integer registers used. #<swps> 9 float registers used. [0] https://cug.org/5-publications/proceedings_attendee_lists/2002CD/S02_Proceedings/Pages/Authors/Cellis.pdf https://cug.org/5-publications/proceedings_attendee_lists/20...

ndesaulniers 5y ago
These are called remarks in GCC and clang and are controlled by -R family of flags.

ndesaulniers 5y ago

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

mhh__ 5y ago

Doesn't do exactly what you want, but try -fopt-info-all in GCC. Gives you a reasonably informative guide of what it tried to do and whether it used the transformation or not.

overgard 5y ago
Thanks! I'll try that.

UncleMeat 5y ago

This would be fun, and it can be made available from the major compilers, but using it almost certainly bad for most developers. Any nonstandard decisions you make here are likely to be unstable. Even if they are better for one build, they will sit in a config file and rot to the point that you've sabotaged your future performance by making decisions for an older build. I see this all the time with nonstandard flags for performance. Somebody five years ago had a problem with the VM and needed to change the way GC worked and set a flag. Nobody remembers why and they are all afraid to touch it. Now the application is getting worse performance.