Maciej Kot (Feb 28 2020 at 00:40): Maciej Kot (Feb 28 2020 at 00:40):Hi, we used to be able to customize compilation by setting cranelift's compile options/flags in Engine's Config. It is no longer possible. Do you have any plans to re-expose compiler config?
In our case, we need to set enable_nan_canonicalization, as we depend on fully deterministic computation, but regardless of this one flag, allowing a full customization of the compilation process seems like a good idea in general.
Peter Huene (Feb 28 2020 at 01:01):Perhaps we should expose a set_compiler_flag(&str, &str) and enable_compiler_flag(&str) method on Config to reintroduce that functionality? cc @Alex Crichton
Alex Crichton (Feb 28 2020 at 01:27):I would be hesitatnt to expose cranelift's full-blown configuration API since it feels too powerful and exposing too much API surface area (and area for accidental breakage), if we can I think it'd be best to encapsulate these configuration options in methods
Dan Gohman (Feb 28 2020 at 01:32):I agree, flags like "is_pic", "avoid_div_traps", and others are things that Wasmtime needs to control for itself.
Dan Gohman (Feb 28 2020 at 01:33):However, it would make sense to expose specific flags, like "enable_nan_canonicalization".
Peter Huene (Feb 28 2020 at 02:17):i would like to side-step the procedural overhead of having to be compiler flag gate keepers, though. I was thinking this would be an advanced (caveat emptor) part of the API, possibly marked unsafe for that reason. perhaps we might go so far as explicitly preventing you from disabling flags we know we need on?
Peter Huene (Feb 28 2020 at 02:18):But if there's really only a need of just supporting a handful of cranelift flags, i'm totally onboard with an abstraction for only those and preventing arbitrary flags
Maciej Kot (Feb 28 2020 at 02:33):Also note that flags can be compiler specific which makes creating explicit methods in the API a little more problematic. Lightbeam does not support nan_canonicalization (I think), so this option should be available only if the Strategy is set to Cranelift.
Till Schneidereit (Feb 28 2020 at 11:46):One option would be to allow the equivalent of -Z flags at least in pre-release versions—i.e. all versions right now :slight_smile: I agree that in the long run we don't want to allow people to set arbitrary Cranelift (or other compiler) flags that we might want to change at any time
Alex Crichton (Feb 28 2020 at 15:49):If we were to add this API then it'd definitely be unsafe, agreed. I'm not really against it per se, I personally think that it's best to have documented and discoverable methods on Config which we can test, fuzz, etc. Escape hatches tend to get forgotten in that it's not clear how to configure them, it's a lot of knowledge that's not really written down, or isn't well supported with tests and such
Alex Crichton (Feb 28 2020 at 15:50):I'd propose trying to add methods to Config, and if it's too much overhead then we could add an unsafe API to tweak it. Also fwiw @Maciej Kot we already have cranelift-specific configuration like the optimization level, we just prefix the configuration with cranelift_*
Chris Fallin (Feb 28 2020 at 17:02):Alex Crichton said:
I'd propose trying to add methods to
Config, and if it's too much overhead then we could add an unsafe API to tweak it.
+1 to a more strongly-typed interface; from the point of view of the new (arm64) backend work, it's marginally nicer for there to be a finite set of methods or fields than to have to interpret a set of key/value strings in a way that's supposed to match the existing behavior.
(Also wrt new backend, there's a separate discussion around which flags are platform-specific and which should work on every platform; I haven't taken a close look at what config options there are today so I guess I don't have too much to say about that yet.)
Last updated: Dec 23 2024 at 13:07 UTC