5 ms·

>This can apply to x86, too. The Intel C/C++ compiler creates different code paths depending on the CPU's capabilities. So at least there's no duplication of n

by Kristine1975 11y ago

>This can apply to x86, too. The Intel C/C++ compiler creates different code paths depending on the CPU's capabilities. So at least there's no duplication of non-cpu-specific code. It also does or at least used to check for the CPU's capabilities by using the CPU's vendor ID string, resulting in AMD CPUs executing the slowest code path: http://agner.org/optimize/blog/read.php?i=49#49 http://agner.org/optimize/blog/read.php?i=49#49 (Intel got sued for this by AMD: https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Criticism https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Critici...) *Edit: >Hopefully some day we can get the same type of system for LLVM IR. Right now the LLVM IR isn't platform-agnostic, e.g. when it comes to calling conventions. Also when Apple transitioned from 68000 to PPC in the 90ies, then from PPC to x86 and recently from 32 bit to 64 bit, they used "fat binaries" where a single executable file contained code for several platforms. That way one and the same application could run on old Macs with PPC, newer ones with 32 bit x86 CPUs and really new ones with 64 bit capable x86 CPUs.

zamalek 11y ago
> The Intel C/C++ compiler creates different code paths depending on the CPU's capabilities. Wow. That's a really slick way to solve the problem. Edit: > Right now the LLVM IR isn't platform-agnostic, e.g. when it comes to calling conventions. That's unfortunate. Either way I'd love to see some form of native IL that can be shipped instead of binaries.
- Kristine1975 11y ago
  >Either way I'd love to see some form of native IL that can be shipped instead of binaries WebAssembly could fit the bill, although it's still in early development.
rwallace 11y ago
> Right now the LLVM IR isn't platform-agnostic, e.g. when it comes to calling conventions. But it does give you the same benefits in terms of CPU capabilities. You can't ship intermediate code that's agnostic about e.g. x86 vs x64 (C and C++ just aren't amenable to that, no matter what your intermediate representation looks like), but you can ship intermediate code that expects some form of x64 but postpones instruction selection until the program is installed, so you can take advantage of new instructions just when they are available. As I understand it, Apple is going to use it for that purpose.

zamalek 11y ago

> The Intel C/C++ compiler creates different code paths depending on the CPU's capabilities. Wow. That's a really slick way to solve the problem. Edit: > Right now the LLVM IR isn't platform-agnostic, e.g. when it comes to calling conventions. That's unfortunate. Either way I'd love to see some form of native IL that can be shipped instead of binaries.

Kristine1975 11y ago
>Either way I'd love to see some form of native IL that can be shipped instead of binaries WebAssembly could fit the bill, although it's still in early development.

rwallace 11y ago

> Right now the LLVM IR isn't platform-agnostic, e.g. when it comes to calling conventions. But it does give you the same benefits in terms of CPU capabilities. You can't ship intermediate code that's agnostic about e.g. x86 vs x64 (C and C++ just aren't amenable to that, no matter what your intermediate representation looks like), but you can ship intermediate code that expects some form of x64 but postpones instruction selection until the program is installed, so you can take advantage of new instructions just when they are available. As I understand it, Apple is going to use it for that purpose.