x64: enable VTune support by default (#3821)

* x64: enable VTune support by default

After significant work in the `ittapi-rs` crate, this dependency should
build without issue on Wasmtime's supported operating systems: Windows,
Linux, and macOS. The difference in the release binary is <20KB, so this
change makes `vtune` a default build feature. This change upgrades
`ittapi-rs` to v0.2.0 and updates the documentation.

* review: add configuration for defaults in more places

* review: remove OS conditional compilation, add architecture

* review: do not default vtune feature in wasmtime-jit

Cargo.toml

@@ -95,6 +95,7 @@ default = [
   "jitdump",
   "wasmtime/wat",
   "wasmtime/parallel-compilation",
+  "vtune",
   "wasi-nn",
   "pooling-allocator",
   "memfd",

crates/jit/Cargo.toml

@@ -22,7 +22,7 @@ gimli = { version = "0.26.0", default-features = false, features = ["std", "read
 object = { version = "0.27.0", default-features = false, features = ["std", "read_core", "elf"] }
 serde = { version = "1.0.94", features = ["derive"] }
 addr2line = { version = "0.17.0", default-features = false }
-ittapi-rs = { version = "0.1.6", optional = true  }
+ittapi-rs = { version = "0.2.0", optional = true  }
 bincode = "1.2.1"
 rustc-demangle = "0.1.16"
 cpp_demangle = "0.3.2"

crates/jit/src/profiling.rs

@@ -12,8 +12,8 @@ cfg_if::cfg_if! {
 }
 
 cfg_if::cfg_if! {
-    if #[cfg(all(feature = "vtune", target_os = "linux"))] {
-        #[path = "profiling/vtune_linux.rs"]
+    if #[cfg(all(feature = "vtune", target_arch = "x86_64"))] {
+        #[path = "profiling/vtune.rs"]
         mod vtune;
     } else {
         #[path = "profiling/vtune_disabled.rs"]

crates/jit/src/profiling/vtune_linux.rs → crates/jit/src/profiling/vtune.rs

@@ -1,10 +1,6 @@
-//! Adds support for profiling JIT-ed code using VTune.
-//!
-//! ### Build
-//!
-//! ```ignore
-//! cargo build --features=vtune
-//! ```
+//! Adds support for profiling JIT-ed code using VTune. By default, VTune
+//! support is built in to Wasmtime (configure with the `vtune` feature flag).
+//! To enable it at runtime, use the `--vtune` CLI flag.
 //!
 //! ### Profile
 //!

crates/wasmtime/Cargo.toml

@@ -60,6 +60,7 @@ default = [
   'cranelift',
   'pooling-allocator',
   'memfd',
+  'vtune',
 ]
 
 # An on-by-default feature enabling runtime compilation of WebAssembly modules

crates/wasmtime/src/lib.rs

@@ -262,8 +262,8 @@
 //!   jitdump runtime profiling format. The profiler can be selected with
 //!   [`Config::profiler`].
 //!
-//! * `vtune` - Not enabled by default, this feature compiles in support for
-//!   supporting VTune profiling of JIT code.
+//! * `vtune` - Enabled by default, this feature compiles in support for VTune
+//!   profiling of JIT code.
 //!
 //! * `uffd` - Not enabled by default. This feature enables `userfaultfd` support
 //!   when using the pooling instance allocator. As handling page faults in user space

docs/examples-profiling-vtune.md

@@ -30,13 +30,10 @@ For more information on VTune and the analysis tools it provides see its
 
 ### Turn on VTune support
 
-For JIT profiling with VTune, first build with the `vtune` feature enabled:
-
-```sh
-$ cargo build --features=vtune
-```
-
-Then, enable runtime support based on how you use Wasmtime:
+For JIT profiling with VTune, Wasmtime currently builds with the `vtune` feature
+enabled by default. This ensures the compiled binary understands how to inform
+the `ittapi` library of JIT events. But it must still be enabled at
+runtime--enable runtime support based on how you use Wasmtime:
 
 * **Rust API** - call the [`Config::profiler`] method with
   `ProfilingStrategy::VTune` to enable profiling of your wasm modules.
@@ -62,7 +59,7 @@ future.
 With VTune [properly installed][download], if you are using the CLI execute:
 
 ```sh
-$ cargo build --features=vtune
+$ cargo build
 $ vtune -run-pass-thru=--no-altstack -collect hotspots target/debug/wasmtime --vtune foo.wasm
 ```
 

docs/examples-profiling.md

@@ -1,9 +1,13 @@
 # Profiling WebAssembly
 
 One of WebAssembly's major goals is to be quite close to native code in terms of
-performance, so typically when executing wasm you'll be quite interested in how
-well your wasm module is performing! From time to time you might want to dive a
-bit deeper into the performance of your wasm, and this is where profiling comes
+performance, so typically when executing Wasm you'll be quite interested in how
+well your Wasm module is performing! From time to time you might want to dive a
+bit deeper into the performance of your Wasm, and this is where profiling comes
 into the picture.
 
-Profiling support in Wasmtime is still under development, but if you're using either [perf](./examples-profiling-perf.md) or [Vtune](./examples-profiling-vtune.md) the examples in these sections are targeted at helping you get some information about the performance of your wasm modules.
+Profiling support in Wasmtime is still under development, but if you're using
+either [perf](./examples-profiling-perf.md) or
+[VTune](./examples-profiling-vtune.md) the examples in these sections are
+targeted at helping you get some information about the performance of your Wasm
+modules.