lkml.org 
[lkml]   [2021]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 04/13] Kbuild: Rust support
    On Thu, Apr 15, 2021 at 8:03 PM Nick Desaulniers
    <ndesaulniers@google.com> 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

    \
     
     \ /
      Last update: 2021-04-16 14:25    [W:2.930 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site