> https://www.intel.com/content/dam/www/public/us/en/documents...

More than you could ever want to know (but see specifically B.4.7.1).

>2. I'm... guessing that gcc/clang are too dumb to be able to >be taught this and get the balance right.

No, actually, you could model this and other things exactly. It's just not worth the cost ;)

I think you're bluffing. I think this particular case is one that is so deep into the processor that no compiler stands a chance of modeling this exactly. :)

But one optimization I'd like to see is convincing the compilers to do better on "macro-op fusion", which let "INC/JCC" type operations be treated as a single µop if they are one after the other. GCC/Clang don't seem to be aware of the benefit of this, and often gratuitously break it by splitting them up.

It's a reasonably rare case where it makes a big difference, but it almost never hurts, and frequently is a small positive. Who would I need to convince to change this? What sort of benchmark would they need as motivation? Would pointing to Intel documentation possibly be sufficient?

I would recommend starting with a test case and a missed optimization bug report.

GCC has some support for macro-ops fusion. [0] is the first message in a gcc-patches thread where the feature was added.

[0] https://gcc.gnu.org/ml/gcc-patches/2013-09/msg00168.html

Thanks, this does indeed look like exact issue I'm referring to. I don't think it ever made it in to release, though. Despite apparent agreement that it's a useful optimization, it appears the final result of the two-month 59-message thread is that after many reworks of the patch and lots of feedback, the OP eventually gives up on getting it included due to interactions with another feature: http://gcc.1065356.n8.nabble.com/Fwd-PATCH-Scheduling-result...

Sorry about that, I thought it was committed. A comparable patch was committed to LLVM version 5, though. [0] is the macro-op fusion pass for x86.

[0] https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X...

> It's a reasonably rare case where it makes a big difference, but it almost never hurts, and frequently is a small positive. Who would I need to convince to change this? What sort of benchmark would they need as motivation? Would pointing to Intel documentation possibly be sufficient?

From someone completely naive on the compiler scene, I think I can safely say that

- A benchmark with better results than it should have (ie, savings on the order of whole seconds) would obviously grab and keep attention

- For finding out who to pester and/or what everyone thinks of the subject, #gcc is big-ish, #llvm is a bit smaller, and #clang is smaller still, all on freenode - presumably low activity (as seems the norm nowadays) and type-and-wait, but a lighter-weight (for want of a better term) alternative than the mailinglists. Ultimately I expect you'll end up posting to a list somewhere, but IRC sounds like a good way to get oriented first

- My strong guess is that LLVM and GCC already have fairly heavily ingrained internal architecture/structure, and yeah, some convincing would be needed.

- I have no idea how to get in touch with people associated with LKML off-LKML, but they seem to have opinions about generated code quality too: https://lkml.org/lkml/2017/11/10/310 (focusing on reply at bottom, not quote; linked in https://news.ycombinator.com/item?id=15849305, from https://news.ycombinator.com/item?id=15845118)

If it was worth the cost, people would do it :)

We actually have done optimal modeling before, using distributed combinatorial optimization.

FWIW Intel documentation is often wrong, so you'd need a real motivating benchmark.

Well, it's a highly specific situation, and what most people use - for widely deployed software - is blended code which is approximately optimal for current-ish CPUs. So probably most work goes into generating blended code. Maybe the Intel compiler can get the code exactly right for i7?