4 ms·

Using "-march=x86-64-v3" is still a decision which has to be made at compile time. I wonder if the Apple appstore (at least watchOS/tvOS) approach of using bitc

Using "-march=x86-64-v3" is still a decision which has to be made at compile time. I wonder if the Apple appstore (at least watchOS/tvOS) approach of using bitcode as the one-time artifact and then turning that into concrete instructions later would be possible for an entire Linux distribution (Gentoo II). The Mill CPU team wants to use something like that OS-wide to hide/emulate entire missing functionality on lower-tier CPU models. Or the other possibility of compiling for all architecture and then selecting this or that function depending on what the current CPU is, or even hotpatching if the security model allows it. I remember either gcc or glibc having some support for one of these.

apocalypses 6y ago
One thing LLVM bitcode still can’t do is retain information about preprocessor directives, eg any platform specific code for AVX2 vs SSE4 etc. So unless you aim to write intrinsic free code it’s usually less performance/reliable to rely on compiler automatic vectorisation, which results in worse codegen overall.
- jcranmer 6y ago
  > One thing LLVM bitcode still can’t do is retain information about preprocessor directives, eg any platform specific code for AVX2 vs SSE4 etc. LLVM supports per-function subtarget attributes, so you can compile individual functions with AVX2 support versus SSE4 support. The clang frontend even has a few different ways of triggering this support, with one method allowing you to specify per-CPU dispatch, and another merely specifying target attributes on a per-function basis.
- wtallis 6y ago
  I know GCC supports generating multiple versions of a function, compiled for different instruction set extensions. And this can also be done manually when you have hand-optimized implementations: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Functio... It's based on a GNU extension to the ELF format, not preprocessor directives. I don't think any of that would conflict with using bitcode for everything you don't have a hand-optimized machine-specific implementation of.
firethief 6y ago
> I wonder if the Apple appstore (at least watchOS/tvOS) approach of using bitcode as the one-time artifact and then turning that into concrete instructions later would be possible for an entire Linux distribution (Gentoo II). I could see this happening with WASM once its system interfaces and SIMD intrinsics mature... "write once, run anywhere"?
ip26 6y ago
Even if you could just pick a few target march... I mean, how many real world compute farms have exactly one march anyway?

apocalypses 6y ago

One thing LLVM bitcode still can’t do is retain information about preprocessor directives, eg any platform specific code for AVX2 vs SSE4 etc. So unless you aim to write intrinsic free code it’s usually less performance/reliable to rely on compiler automatic vectorisation, which results in worse codegen overall.

jcranmer 6y ago
> One thing LLVM bitcode still can’t do is retain information about preprocessor directives, eg any platform specific code for AVX2 vs SSE4 etc. LLVM supports per-function subtarget attributes, so you can compile individual functions with AVX2 support versus SSE4 support. The clang frontend even has a few different ways of triggering this support, with one method allowing you to specify per-CPU dispatch, and another merely specifying target attributes on a per-function basis.
wtallis 6y ago
I know GCC supports generating multiple versions of a function, compiled for different instruction set extensions. And this can also be done manually when you have hand-optimized implementations: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Functio... It's based on a GNU extension to the ELF format, not preprocessor directives. I don't think any of that would conflict with using bitcode for everything you don't have a hand-optimized machine-specific implementation of.

firethief 6y ago

> I wonder if the Apple appstore (at least watchOS/tvOS) approach of using bitcode as the one-time artifact and then turning that into concrete instructions later would be possible for an entire Linux distribution (Gentoo II). I could see this happening with WASM once its system interfaces and SIMD intrinsics mature... "write once, run anywhere"?

ip26 6y ago

Even if you could just pick a few target march... I mean, how many real world compute farms have exactly one march anyway?