[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48a98d0c-bfd1-68a9-5d1f-65c942b7c0ef@crisal.io>
Date: Mon, 19 Jun 2023 13:27:05 +0200
From: Emilio Cobos Álvarez <emilio@...sal.io>
To: Andrew Lunn <andrew@...n.ch>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, kuba@...nel.org,
netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, aliceryhl@...gle.com
Subject: Re: [PATCH 0/5] Rust abstractions for network device drivers
Hi Andrew, Miguel,
On 6/16/23 16:43, Andrew Lunn wrote:
> I said in another email, i don't want to suggest premature
> optimisation, before profiling is done. But in C, these functions are
> inline for a reason. We don't want the cost of a subroutine call. We
> want the compiler to be able to inline the code, and the optimiser to
> be able to see it and generate the best code it can.
>
> Can the rust compile inline the binding including the FFI call?
This is possible, with cross-language LTO, see:
https://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html
There are some requirements that need to happen for that to work
(mainly, I believe, that the LLVM version used by rustc and clang agree).
But in general it is possible. We use it extensively on Firefox. Of
course the requirements of Firefox and the kernel might be different.
I think we rely heavily on PGO instrumentation to make the linker inline
ffi functions, but there might be other ways of forcing the linker to
inline particular calls that bindgen could generate or what not.
Cheers,
-- Emilio
Powered by blists - more mailing lists