On Thu, Apr 15, 2021 at 8:03 PM Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > Until then, I don't see why we need to permit developers to express > such flexibility for just the Rust code, or have it differ from the > intent of the C code. Does it make sense to set RUST_OPT_LEVEL_3 and > CC_OPTIMIZE_FOR_SIZE? I doubt it. That doesn't seem like a development > feature, but a mistake. YAGNI. Instead developers should clarify > what they care about in terms of high level intent; if someone wants > to micromanage optimization level flags in their forks they don't need > a Kconfig to do it (they're either going to hack KBUILD_CFLAGS, > CFLAGS_*.o, or KCFLAGS), and there's probably better mechanisms for > fine-tooth precision of optimizing actually hot code or not via PGO > and AutoFDO. I completely agree when we are talking about higher level optimization levels. From a user perspective, it does not make much sense to want slightly different optimizations levels or different size/performance trade-offs between C and Rust. However, I am thinking from the debugging side, i.e. mostly low or no optimization; rather than about micromanaging optimizations for performance. For instance, last year I used `RUST_OPT_LEVEL_0/1` to quickly rule out optimizer/codegen/etc. bugs on the Rust side when we had some memory corruption over Rust data (https://github.com/Rust-for-Linux/linux/pull/28), which is important when dealing with compiler nightly versions. It was also nice to be able to easily follow along when stepping, too. Having said that, I agree that in those cases one can simply tweak the flags manually -- so that's why I said it is fine dropping the the `Kconfig` options. There might be some advantages of having them, such as making developers aware that those builds should work, to keep them tested/working, etc.; but we can do that manually too in the CI/docs too. Cheers, Miguel
