Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does a compiler use all x86 instructions? (2010)

pepijndevos.nl

Post reply on HN
Print view View original

21–30 of 198 posts

Re: Does a compiler use all x86 instructions? (2010)

#21

Post by saynsedit »

Majster wrote: post #3
ajenner wrote: post #2

It doesn't, because there are lots of special-purpose x86 instructions that would be more trouble than they're worth to teach a compiler about. For example, instructions for accessing particular CPU features that the C and C++ languages have no concept of (cryptographic acceleration and instructions used for OS kernel code spring to mind). Some of these the compiler might know about via intrinsic functions, but won't…

Could you provide some links or examples? I'd love to learn more about this.

Just read the output of your compiler for simple functions. objdump -d, or, cc -S

Re: Does a compiler use all x86 instructions? (2010)

#22

Post by [deleted] »

Majster wrote: post #3
ajenner wrote: post #2

It doesn't, because there are lots of special-purpose x86 instructions that would be more trouble than they're worth to teach a compiler about. For example, instructions for accessing particular CPU features that the C and C++ languages have no concept of (cryptographic acceleration and instructions used for OS kernel code spring to mind). Some of these the compiler might know about via intrinsic functions, but won't…

Could you provide some links or examples? I'd love to learn more about this.

[deleted]

Re: Does a compiler use all x86 instructions? (2010)

#23

Post by rwmj »

nneonneo wrote: post #17
rwmj wrote: post #14

Earlier quoted context omitted.

And the counterpoint is that some instructions that are commonly believed to be slow (eg. the string instructions like rep movs, lods, stos), are in fact fast on modern processors.

Now I'm curious - do you have performance numbers somewhere for this? The rep instructions can actually be shorter than a call to str*, so if rep is actually fast enough then it might make a nice optimization.

It depends if the strings are aligned or not, the size of the copy, and also on the generation of processor. There are some good answers here:

http://stackoverflow.com/a/9177369

https://stackoverflow.com/questions/12359228/reliable-inform...

https://stackoverflow.com/questions/8425022/performance-of-x...

Re: Does a compiler use all x86 instructions? (2010)

#26

Post by cperciva »

rwmj wrote: post #20
dibanez wrote: post #16

Earlier quoted context omitted.

Yea, I've seen compilers use lea for some integer math in C/C++, because it is handled by a different part of the CPU and so can happen in parallel with other integer math ops.

People might say this, but it's not really true. All these instructions are decomposed into micro-ops, and then the micro-ops are run in parallel - if data dependencies allow that - on a common pool of integer ALUs. The reason to use lea is for code compression - it allows you to express two or three operations in a single instruction.

On some Intel CPUs there are separate address-computation execution units.

Re: Does a compiler use all x86 instructions? (2010)

#28

Post by cfallin »

nneonneo wrote: post #12
api wrote: post #7

Earlier quoted context omitted.

There are also AFIAK a few "deprecated" instructions that are implemented for backward compatibility but do not perform well on modern cores or have much better modern alternatives. These would be things like old MMX instructions, cruft left over from the 16-bit DOS days, etc. X86 is crufty. Of course all old architectures are crufty, and using microcode it's probably possible to keep the cruft from taking up much si…

Good examples of (essentially-deprecated) instructions include the rep prefixed instructions for string operations (modern library code for string operations typically involve a mixture of SSE, full-word loads and unrolled loops for speed); the "loop" instruction (compilers usually generate explicit loops for flexibility); pretty much all the BCD arithmetic instructions (since programming languages don't typically us…

> the rep prefixed instructions for string operations

... are actually preferred over a hand-written vectorized loop on Ivy Bridge and up (see [1] section 3.7.7, "Enhanced REP MOVSB and STOSB operation (ERMSB)"). It's indicated by a CPUID feature flag bit (edit: grep for "erms" in /proc/cpuinfo to see this).

The reason is that microcode knows more about the dcache microachitecture, load/store units, special features (weak ordering with fence at end? [2]), etc., than you do, and can be specially optimized for the particular design. There's a slight cost to transitioning to microcode and back (to ordinary hardware-decoded instructions), of course, so for small operations it might not be a win.

The section cited above shows ERMSB as ~break-even vs. 128 bit AVX on Ivy Bridge from 128 bytes up to 2KB, and about 2% faster above that.

[1] Intel 64 and IA-32 Architectures Optimization Reference Manual (order #248966-026), April 2012. http://www.intel.com/content/dam/doc/manual/64-ia-32-archite...

[2] http://stackoverflow.com/questions/33480999/how-can-the-rep-...

Re: Does a compiler use all x86 instructions? (2010)

#30

Post by detaro »

sytelus wrote: post #25
Hydraulix989 wrote: post #13

mov is Turing complete

Source?

paper: https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf

compiler implementing it: https://github.com/xoreaxeaxeax/movfuscator

HN discussions of these links: https://news.ycombinator.com/item?id=6309631 (paper) and https://news.ycombinator.com/item?id=9751312 (compiler)

Post reply on HN