-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 3 pull requests #115281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 3 pull requests #115281
Conversation
This flag is intended for evaluation of trait upcasting space cost for embedded use cases.
Signed-off-by: ozkanonur <[email protected]>
Add an (perma-)unstable option to disable vtable vptr This flag is intended for evaluation of trait upcasting space cost for embedded use cases. Compared to the approach in rust-lang#112355, this option provides a way to evaluate end-to-end cost of trait upcasting. Rationale: rust-lang#112355 (comment) ## How this flag should be used (after merge) Build your project with and without `-Zno-trait-vptr` flag. If you are using cargo, set `RUSTFLAGS="-Zno-trait-vptr"` in the environment variable. You probably also want to use `-Zbuild-std` or the binary built may be broken. Save both binaries somewhere. ### Evaluate the space cost The option has a direct and indirect impact on vtable space usage. Directly, it gets rid of the trait vptr entry needed to store a pointer to a vtable of a supertrait. (IMO) this is a small saving usually. The larger saving usually comes with the indirect saving by eliminating the vtable of the supertrait (and its parent). Both impacts only affects vtables (notably the number of functions monomorphized should , however where vtable reside can depend on your relocation model. If the relocation model is static, then vtable is rodata (usually stored in Flash/ROM together with text in embedded scenario). If the binary is relocatable, however, the vtable will live in `.data` (more specifically, `.data.rel.ro`), and this will need to reside in RAM (which may be a more scarce resource in some cases), together with dynamic relocation info living in readonly segment. For evaluation, you should run `size` on both binaries, with and without the flag. `size` would output three columns, `text`, `data`, `bss` and the sum `dec` (and it's hex version). As explained above, both `text` and `data` may change. `bss` shouldn't usually change. It'll be useful to see: * Percentage change in text + data (indicating required flash/ROM size) * Percentage change in data + bss (indicating required RAM size)
…=Mark-Simulacrum replace outdated github username 'ozkanonur'
…mats, r=notriddle Unify CSS color formats a bit more When `rgb` format doesn't have an `rgba` equivalent, I turned it into hex format. I also "decapitalized" hex formats. r? `@notriddle`
@bors r+ p=3 rollup=never |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 668bf8c593 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (8550f15): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 631.179s -> 630.803s (-0.06%) |
Successful merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup