T Compiler Meeting Agenda 2023 07 27

T-compiler Meeting Agenda 2023-07-27

Announcements

  • A Rust release 1.71.1 is scheduled for August, 3rd (comment)
  • Compiler Team Planning meeting at time:2023-07-28T10:00:00-04:00
  • An interesting Zulip thread about a possible date for a 2024 edition
    • Spoiler: could be around Nov, 28th 2024 (Rust ~1.83.0)
  • Reminder: if you see a PR/issue that seems like there might be legal implications due to copyright/IP/etc, please let the Core team know (or at least message @pnkfelix or @Wesley Wiser so we can pass it along).

Other WG meetings (calendar link)

MCPs/FCPs

  • New MCPs (take a look, see if you like them!)
    • No new proposals this time.
  • Old MCPs (stale MCP might be closed as per MCP procedure)
    • None at this time
  • Old MCPs (not seconded, take a look)
    • “Cell Broadband Engine SPU support” compiler-team#614(last review activity: 3 months ago)
    • “Add support for Zephyr OS” compiler-team#629(last review activity: about 35 days ago)
    • “Consistently use “region” terminology in later stages of the compiler” compiler-team#634(last review activity: 2 months ago)
    • “Add a new --build-id flag to rustc” compiler-team#635(last review activity: 2 months ago)
    • “Simplify and improve explicitness of the check-cfg syntax” compiler-team#636(last review activity: about 42 days ago)
    • “Add support for visionOS targets” compiler-team#642(last review activity: about 27 days ago)
    • “Add illumos Tier3 targets” compiler-team#644(last review activity: about 2 days ago)
    • “Migrate away from u32 as an offset/length type” compiler-team#647(last review activity: about 20 days ago)
  • Pending FCP requests (check your boxes!)
    • “Retire the mailing list and make all decisions on zulip” compiler-team#649
      • Note: pending 2 concerns
    • “Support overriding warnings level for a specific lint via command line” rust#113307
  • Things in FCP (make sure you’re good with it)
  • Accepted MCPs
  • Finalized FCPs (disposition merge)
    • “Add documentation on v0 symbol mangling.” rust#97571
    • “Support interpolated block for try and async” rust#112953

WG checkins

Backport nominations

T-compiler stable / T-compiler beta

  • :beta: [1.72.0] “lint/ctypes: fix () return type checks” rust#113457
    • Fixes #113436, a warn-by-default after T-libs decision to proceed
    • perf run indicates neutral changes
  • :beta: [1.72.0] “Substitute types before checking inlining compatibility.” rust#113802
    • Fixes #112332 and #113781, two ICEs (one dupe of the other, btw), one affecting a old version of a real-world crate (updated since then)
    • Also nominated for stable backport
  • :stable: [1.71.1] “Don’t use can_eq in derive(..) suggestion for missing method” rust#111516
    • Fixes regression #111500, ICE on invalid code but reported also on sibling issues #114049 and 114056
  • :stable: [1.71.1] “suspicious_double_ref_op: don’t lint on .borrow()” rust#112517
    • Fixes #112489, P-medium diag regression
  • :stable: [1.71.1] “Substitute types before checking inlining compatibility.” rust#113802

PRs S-waiting-on-team

T-compiler

Issues of Note

Short Summary

P-critical

T-compiler

  • No P-critical issues for T-compiler at this time.

T-types

  • No P-critical issues for T-types at this time.

T-rustdoc

  • No P-critical issues for T-rustdoc at this time.

P-high regressions

P-high beta regressions

  • No P-high beta regressions this time.

Unassigned P-high nightly regressions

  • No unassigned P-high nightly regressions this time.

Performance logs

Triage logs for 2023-07-26

A relatively light week with respect to performance changes. The one major regressing PR was reverted (for other reasons), and we saw some very nice gains on compile-times from (1.) changes to our codegen-unit merging logic and from (2.) changes to the stdlib slice iterators encoding its non-null guarantees directly, allowing the removal of a call to the assume intrinsic.

Triage done by @pnkfelix. Revision range: 6b9236ed..0308df23

Summary:

(instructions:u) mean range count
Regressions (primary) 1.4% [0.6%, 10.2%] 27
Regressions (secondary) 1.1% [0.3%, 2.9%] 19
Improvements (primary) -2.2% [-8.3%, -0.4%] 21
Improvements (secondary) -1.6% [-2.0%, -1.2%] 2
All (primary) -0.2% [-8.3%, 10.2%] 48

1 Regressions, 1 Improvements, 4 Mixed; 1 of them in rollups 30 Untriaged Pull Requests 35 artifact comparisons made in total

Regressions

Prototype: Add unstable -Z reference-niches option #113166 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 0.7% [0.3%, 1.1%] 19
Regressions (secondary) 1.0% [0.3%, 1.2%] 4
Improvements (primary) - - 0
Improvements (secondary) - - 0
All (primary) 0.7% [0.3%, 1.1%] 19
  • reverted in PR #113946
  • marked as triaged

Improvements

Inline overlap based CGU merging #113777 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 1.2% [1.2%, 1.2%] 1
Regressions (secondary) - - 0
Improvements (primary) -1.8% [-4.5%, -0.3%] 11
Improvements (secondary) - - 0
All (primary) -1.6% [-4.5%, 1.2%] 12

this improved instruction-counts for 9 opt-full primary benchmarks. (The one regression was to regex-1.5.5 opt-full, by -1.15%; but the wins elsewhere pay for this.)

As noted by @nnethercote , this results in nearly 10second reduction in bootstrap time (i.e. -1.495%, no small feat at all!)

Mixed

Turn copy into moves during DSE. #113758 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 9.4% [9.4%, 9.4%] 1
Regressions (secondary) 0.6% [0.6%, 0.6%] 1
Improvements (primary) -1.0% [-2.1%, -0.2%] 14
Improvements (secondary) -0.8% [-1.3%, -0.2%] 2
All (primary) -0.3% [-2.1%, 9.4%] 15
  • regression is to webrender-2022 opt incr-patched, (by 9.4%, as you can see from the above)
  • from the flamegraphs, seems like codegen_module_perform_lto went from 8.6 seconds to 9.6 seconds, with half of the growth in LLVM_lto_optimize, and half in LLVM_module_codegen_emit_obj.
  • not marking as triaged for now.

Rollup of 7 pull requests #113890 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) - - 0
Regressions (secondary) 0.2% [0.2%, 0.2%] 1
Improvements (primary) -0.3% [-0.3%, -0.2%] 4
Improvements (secondary) - - 0
All (primary) -0.3% [-0.3%, -0.2%] 4
  • that doesn’t seem worth dissecting
  • marking as triaged
  • (the specific secondary is tt-muncher check incr-unchanged 0.23%)

Always const-prop scalars and scalar pairs #113858 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 0.8% [0.3%, 3.3%] 42
Regressions (secondary) 0.7% [0.2%, 1.1%] 19
Improvements (primary) -0.6% [-1.3%, -0.2%] 6
Improvements (secondary) - - 0
All (primary) 0.6% [-1.3%, 3.3%] 48
  • we didn’t anticipate such a high impact to the instruction-counts; the trial run said there were two primary regressions here, not 42.
    • exa-0.10.1 opt-full regressed by 3.34%
    • five various bitmaps-3.1.0 profiles/scenarios regressed by 1.01% to 1.21%
    • ripgrep-13.0.0 check-incr-unchanged regressed by 1.01%
    • bunch of others that regressed by a little less than 1%… seems not great.
  • not marking as triaged.

Get !nonnull metadata on slice iterators, without assumes #113344 (Comparison Link)

(instructions:u) mean range count
Regressions (primary) 8.3% [8.3%, 8.3%] 1
Regressions (secondary) - - 0
Improvements (primary) -1.1% [-8.3%, -0.5%] 63
Improvements (secondary) -0.7% [-1.1%, -0.3%] 15
All (primary) -1.0% [-8.3%, 8.3%] 64
  • cranelift-codegen-0.82.1 opt-full regressed by 8.31%
  • a slew of other benchmarks improved (regex-1.5.5 incr-patched by -8.28%, bitmaps incr by 1.2-1.4%, the rest by -1% or less)
  • overall, a nice win. That’s enough to let me mark this as triaged.

Nominated Issues

T-compiler

  • “MSVC and rustc disagree on minimum stack alignment on x86 Windows” rust#112480
    • Discussed in the past 2 meetings (here and here), left nominated for further discussion (maybe in a separate session)
  • ““Legacy” tier 2 targets have misplaced or absent maintainer docs” rust#113739
    • Discussed in the past meeting (here), left nominated for further discussion (maybe in a separate session)
  • “Add tidy rule against issue-[0-9]+.rs tests” compiler-team#658
    • an MCP proposing to remove the issue # from UI tests filename, considered lacking semantic information
    • other proposals point to keeping the issue # as it is descriptive of the issue(s), with variations around “issue-123456-”
    • maybe enforcing a descriptive first-line comment in the test file (e.g. // #12345 Fixed redundant streaming problem)
    • thoughts from Jack

tl;dr There are two things we should discuss: 1) This seems like a process failure and we should think about scheduling a discussion around MCPs (and when waiting the full 10 days is appropriate and when it’s unnecessary). 2) Do we like this MCP/PR as-is, is it okay-enough to stay on master until we figure out a better solution, or should we revert?

First, it kind of irks me that this was pushed through without waiting for the full 10 days of MCP, and I wonder if there’s a discussion to be had about process here. (I’m not sure if we reevaluated if MCPs are working or not, etc.) This is clearly the type of PR that MCPs are meant for: changes that have wide-ranging effects on compiler development. The PR itself even got some comments one way or the other, and so does the (now created) MCP zulip thread. AND there was even this note in the PR OP: “note: between the creation of this PR and 2023-07-25 (14 days), 10 more tests were added that failed this check.” So, people are obviously using this pattern at a high frequency. Really, this should have waited for more visibility before merge.

For the actual substance of the PR/MCP, a few thoughts. First, it’s not clear to me if something like issue-12345-invalid-fn-name.rs would be allowed or not (doesn’t seem like it is, but this seems to have been heavily favored in the comments as a minimum for what should be allowed). Second, it doesn’t seem the places/situations where file names like issue-12345.rs actually makes decent sense were even considered: bug tests where we’re there’s an open issue, issues reported through fuzzing where the actual program is ICE->error, issues that have been fixed since being opened and it’s not clear what exactly the problem was. I also think the test naming is evidence of a more subtle pattern: we very often today commit tests as-is from issues. This is maybe okay when there is one issue that a given PR fixes. But, it starts to get interesting when you have a PR that fixes multiple related issues. Now, we’re in the dilemma of “are these tests similar enough to each other that they should just be only one test file, or could they be triggered separately”. This change could help with that, by making it more work to add regression tests exactly, but I’m not sure “more work” is a good solution. (Aside, I don’t personally agree that issue-12345.rs doesn’t give enough context to what the test is for: it’s a regression test from a reported issue).

  • “coverage: Replace ExpressionOperandId with enum Operand rust#113428
    • nominated to help find a reviewer with some context
  • “Support --print KIND=PATH command line syntax by rust#113780
    • Nominated by @Urgau (comment): asks if this change shouldn’t have gone through some signal boosting / approval procedure before being merged

RFC

  • No I-compiler-nominated RFCs this time.

Oldest PRs waiting for review

T-compiler

  • “Fix suggestion spans for expr from macro expansions” rust#112043 (last review activity: about 28 days ago)
    • cc @cjgillot
  • “Tait must be constrained if in sig” rust#113169 (last review activity: about 27 days ago)
    • cc @oli (appointed as self reviewer)
  • “Report allocation errors as panics, second attempt” rust#112331 (last review activity: about 26 days ago)
    • cc: @bjorn3 (though T-libs also in the review loop)

Next week’s WG checkins

Next agenda draft: https://hackmd.io/LLdrdTZPT06xMPq9a1gYcQ