You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR enables cross language LTO for our release builds, meaning
function calls from external C dependencies like `libdecimal` can
potentially get inlined into Rust code.
The way this works is when building our final binaries, e.g.
`environmentd` and `clusterd`, we specify the `-Clinker-plugin-lto` flag
to `rustc` which has our linker (`lld`) run the LTO passes instead of
`rustc`. At which point all of our Rust and C code has been compiled to
LLVM bitcode so to `lld` is free to optimize across languages.
This only works when building for Linux. Arguments that `rustc` passes
to the linker when targetting macOS don't seem to be supported by
`ld64.lld`? See rust-lang/rust#60059 for some
more investigation.
### Motivation
Faster runtime performance.
### Tips for reviewer
The commits are broken down as follows:
1. Some Bazel configuration so we can detect when the cross language LTO
is requested _and_ when we're building on a Linux machine.
2. Updates to cargo-gazelle so we specify the right `rustc` flags.
Theoretically something like this could be upstreamed into `rules_rust`
which I started working on in
bazelbuild/rules_rust#3162. But for now updating
cargo-gazelle is a lot easier.
3. Running `bin/bazel gen`
### Checklist
- [ ] This PR has adequate test coverage / QA involvement has been duly
considered. ([trigger-ci for additional test/nightly
runs](https://trigger-ci.dev.materialize.com/))
- [ ] This PR has an associated up-to-date [design
doc](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/README.md),
is a design doc
([template](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/00000000_template.md)),
or is sufficiently small to not require a design.
<!-- Reference the design in the description. -->
- [ ] If this PR evolves [an existing `$T ⇔ Proto$T`
mapping](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/command-and-response-binary-encoding.md)
(possibly in a backwards-incompatible way), then it is tagged with a
`T-proto` label.
- [ ] If this PR will require changes to cloud orchestration or tests,
there is a companion cloud PR to account for those changes that is
tagged with the release-blocker label
([example](https://github.com/MaterializeInc/cloud/pull/5021)).
<!-- Ask in #team-cloud on Slack if you need help preparing the cloud
PR. -->
- [ ] If this PR includes major [user-facing behavior
changes](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/guide-changes.md#what-changes-require-a-release-note),
I have pinged the relevant PM to schedule a changelog post.
0 commit comments