Stream: t-compiler

Topic: weekly meeting 2020-04-30 #54818


Santiago Pastorino (Apr 29 2020 at 19:02, on Zulip):

Hi @T-compiler/meeting; the triage meeting will be starting in ~ 20 hours

Santiago Pastorino (Apr 29 2020 at 19:03, on Zulip):

The @WG-prioritization will be doing pre-triage in #t-compiler/wg-prioritization > pre-meeting triage 2020-04-30 #54818

Santiago Pastorino (Apr 29 2020 at 19:04, on Zulip):

During pre-triage we will be preparing the meeting agenda

Santiago Pastorino (Apr 29 2020 at 19:06, on Zulip):

we will have checkins from Polymorphization WG and @WG-prioritization

Santiago Pastorino (Apr 29 2020 at 19:06, on Zulip):

@davidtwco do you have something you want to share about Polymorphization?

Santiago Pastorino (Apr 29 2020 at 19:07, on Zulip):

I can share some things about Prioritization

davidtwco (Apr 29 2020 at 19:07, on Zulip):

I'll post an update in a moment - got an exam tomorrow so won't be around for the meeting.

davidtwco (Apr 29 2020 at 19:11, on Zulip):

I can't remember where the polymorphisation work was last time I gave an update at the meeting, so to remind everyone, the polymorphisation working group is for tracking my master's project - implementing an analysis that will detect when generic parameters are unused, and then reducing monomorphisation as a result.

#69749 has a working implementation of polymorphisation (I've paused working on it until my exams are over), which we've run perf on and gotten mixed results - there are some interesting interactions with LTO on one benchmark configuration, and some cases see 3-5% improvements, but some are worse-off (normally by 1-2%). There's probably some room for improvement yet.

mark-i-m (Apr 30 2020 at 02:31, on Zulip):

All the best on your exams!

Santiago Pastorino (Apr 30 2020 at 13:36, on Zulip):

Hi @T-compiler/meeting, triage meeting will be starting in ~ 23 minutes

Santiago Pastorino (Apr 30 2020 at 13:37, on Zulip):

Check out the meeting agenda

pnkfelix (Apr 30 2020 at 14:00, on Zulip):

Hi @T-compiler/meeting! Add a :wave: emoji to show you're here :)

pnkfelix (Apr 30 2020 at 14:01, on Zulip):

we will start off with 5 minutes for ...

pnkfelix (Apr 30 2020 at 14:01, on Zulip):

Announcements

pnkfelix (Apr 30 2020 at 14:01, on Zulip):
pnkfelix (Apr 30 2020 at 14:02, on Zulip):

(there was a point raised, btw, about whether we should wait for an MCP to be "seconded" before we announce it here.)

pnkfelix (Apr 30 2020 at 14:02, on Zulip):

(My current inclination is to go ahead and announce it here prior to it being seconded. But if things get out of control, we can revisit that later.)

pnkfelix (Apr 30 2020 at 14:03, on Zulip):
pnkfelix (Apr 30 2020 at 14:04, on Zulip):

the members present tentatively agreed to try doing so. Its worth noting that the representative from T-libs, @David Tolnay , said that the main goal was to try to ease up the PR review burden

pnkfelix (Apr 30 2020 at 14:05, on Zulip):

but one example of a change that we have implemented in response to this is that we will be looking at T-libs backport nominations today

pnkfelix (Apr 30 2020 at 14:05, on Zulip):

speaking of steering meetings ... where are we on the schedule there ...

pnkfelix (Apr 30 2020 at 14:06, on Zulip):
pnkfelix (Apr 30 2020 at 14:07, on Zulip):
pnkfelix (Apr 30 2020 at 14:08, on Zulip):

So, okay, that's all the announcements I have

pnkfelix (Apr 30 2020 at 14:08, on Zulip):

lets move onto the agenda

Wesley Wiser (Apr 30 2020 at 14:08, on Zulip):

I'd just like to call attention again to the "Implement LLVM-compatible source-based code coverage" MCP. It's currently in need of feedback about the approach and someone familiar with the frontend of the compiler to second it.

pnkfelix (Apr 30 2020 at 14:08, on Zulip):

Thanks @Wesley Wiser

pnkfelix (Apr 30 2020 at 14:09, on Zulip):

cc @Vadim Petrochenkov ^

pnkfelix (Apr 30 2020 at 14:09, on Zulip):

okay, so, for T-compiler beta-noms, we have four on the agenda

pnkfelix (Apr 30 2020 at 14:09, on Zulip):

beta-nom 1/4: "Quick and dirty fix of the unused_braces lint" #71517

pnkfelix (Apr 30 2020 at 14:11, on Zulip):

/me was worried by the "dirty" in the title

pnkfelix (Apr 30 2020 at 14:11, on Zulip):

but this doesn't seem that bad; at least, I won't block a backport on it...

pnkfelix (Apr 30 2020 at 14:12, on Zulip):

T-rustdoc is very under-resourced right now, right?

pnkfelix (Apr 30 2020 at 14:12, on Zulip):

as in, we probably shouldn't expect a fix for this in rustdoc anytime soon?

Wesley Wiser (Apr 30 2020 at 14:12, on Zulip):

Yes, I believe so.

pnkfelix (Apr 30 2020 at 14:12, on Zulip):

anyway, beta approved

pnkfelix (Apr 30 2020 at 14:12, on Zulip):

beta-nom 2/4: "normalize field projection ty to fix broken MIR issue" #71488

pnkfelix (Apr 30 2020 at 14:13, on Zulip):

yeah seems fine

pnkfelix (Apr 30 2020 at 14:14, on Zulip):

beta-approved

pnkfelix (Apr 30 2020 at 14:14, on Zulip):

beta-nom 3/4: "fix error code in E0751.md" #71426

pnkfelix (Apr 30 2020 at 14:15, on Zulip):

so, this does seem very low-risk

pnkfelix (Apr 30 2020 at 14:15, on Zulip):

but ... is it high priority?

pnkfelix (Apr 30 2020 at 14:15, on Zulip):

@Esteban Küber nominated, maybe they can explain?

nikomatsakis (Apr 30 2020 at 14:16, on Zulip):

I guess it's just that it gives the .. wrong error code?

pnkfelix (Apr 30 2020 at 14:16, on Zulip):

I cannot tell based on the issues when this was injected

nikomatsakis (Apr 30 2020 at 14:16, on Zulip):

it was my PR that added negative impls

nikomatsakis (Apr 30 2020 at 14:16, on Zulip):

but

pnkfelix (Apr 30 2020 at 14:16, on Zulip):

if this was truly injected so recently that its only on the beta

nikomatsakis (Apr 30 2020 at 14:16, on Zulip):

negative impls are unstable and can only be used on nightly etc

nikomatsakis (Apr 30 2020 at 14:16, on Zulip):

I'd say it's low priority and not worth backporting

nikomatsakis (Apr 30 2020 at 14:16, on Zulip):

i.e., this error can only arise when building libstd more or less :P

nikomatsakis (Apr 30 2020 at 14:16, on Zulip):

ok, that's not true, but it does require nightly builds

pnkfelix (Apr 30 2020 at 14:17, on Zulip):

okay, lets decline and let @Esteban Küber argue for the opposition if they so choose

pnkfelix (Apr 30 2020 at 14:17, on Zulip):

beta-nom 4/4: "Remove some Vec allocations to improve performance" #71268

pnkfelix (Apr 30 2020 at 14:18, on Zulip):

/me has realization: if we get a bot to start spitting out the titles above, then @pnkfelix will get to start voting for themself!

nikomatsakis (Apr 30 2020 at 14:19, on Zulip):

ooh, nice

pnkfelix (Apr 30 2020 at 14:19, on Zulip):

can anyone give me a summary of how much performance PR #71268 wins back?

Santiago Pastorino (Apr 30 2020 at 14:19, on Zulip):
wf-projection-stress-65510-che...
    avg: -7.8%  min: -11.7% max: -0.4%
wf-projection-stress-65510-deb...
    avg: -7.7%  min: -11.7% max: -0.4%
wf-projection-stress-65510-opt
    avg: -7.7%  min: -11.6% max: -0.4%
futures-check
    avg: -3.5%  min: -7.0%  max: -0.5%
futures-debug
    avg: -2.6%  min: -5.1%  max: -0.4%
serde-check
    avg: -3.1%  min: -4.6%  max: -0.4%
serde-debug
    avg: -2.8%  min: -4.2%  max: -0.4%
tokio-webpush-simple-check
    avg: -1.6%  min: -4.2%  max: -0.1%
serde-opt
    avg: -2.7%  min: -4.0%  max: -0.4%
futures-opt
    avg: -2.0%  min: -3.8%  max: -0.4%
cargo-check
    avg: -0.9%  min: -1.9%  max: -0.0%
Santiago Pastorino (Apr 30 2020 at 14:20, on Zulip):

https://perf.rust-lang.org/compare.html?start=8ce3f840ae9b735a66531996c32330f24b877cb0&end=56be31fea40c74872156aabb1bcf41a5f55e0fd4

pnkfelix (Apr 30 2020 at 14:20, on Zulip):

thx

nikomatsakis (Apr 30 2020 at 14:20, on Zulip):

seems pretty harmless

nikomatsakis (Apr 30 2020 at 14:20, on Zulip):

not sure how imp't it is though

pnkfelix (Apr 30 2020 at 14:20, on Zulip):

yeah okay. I am always a little hestitant about backporting performance improvements

pnkfelix (Apr 30 2020 at 14:20, on Zulip):

unless they are truly no-brainers

eddyb (Apr 30 2020 at 14:20, on Zulip):

wf-projection-stress-65510 tries to mimic a real-world codebase, so I think there are places where this will matter

eddyb (Apr 30 2020 at 14:21, on Zulip):

well, it's fixing a regression

pnkfelix (Apr 30 2020 at 14:21, on Zulip):

yeah but performance regressions are ...

pnkfelix (Apr 30 2020 at 14:21, on Zulip):

... not binary states...

pnkfelix (Apr 30 2020 at 14:22, on Zulip):

anyway its fine, lets backport

pnkfelix (Apr 30 2020 at 14:22, on Zulip):

beta approved

Esteban Küber (Apr 30 2020 at 14:22, on Zulip):

It only missed the train because of timing issues even after approval

pnkfelix (Apr 30 2020 at 14:22, on Zulip):

fair enough

pnkfelix (Apr 30 2020 at 14:22, on Zulip):

so, as I mentioned above

pnkfelix (Apr 30 2020 at 14:22, on Zulip):

this week we have some T-libs beta nominations to look at too

Esteban Küber (Apr 30 2020 at 14:22, on Zulip):

And ameliorates a big timing regression :blush:

pnkfelix (Apr 30 2020 at 14:23, on Zulip):

(there was a separate discussion about whether we can asynchronously handle low-risk beta-backport nominations; we'll hopefully talk more about that next week.)

Esteban Küber (Apr 30 2020 at 14:23, on Zulip):

Btw, re the doc backport, I proposed it to avoid the wrong documentation ending up in the public facing website.

pnkfelix (Apr 30 2020 at 14:23, on Zulip):

T-libs beta-nom 1/1: "Update stdarch submodule" #71495

pnkfelix (Apr 30 2020 at 14:24, on Zulip):

pnkfelix said:

(there was a separate discussion about whether we can asynchronously handle low-risk beta-backport nominations; we'll hopefully talk more about that next week.)

aforementioned conversion: https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/t-libs.20issues.20in.20the.20meeting.20agenda.3F/near/195839368

nikomatsakis (Apr 30 2020 at 14:24, on Zulip):

Esteban Küber said:

Btw, re the doc backport, I proposed it to avoid the wrong documentation ending up in the public facing website.

ah, interesting

pnkfelix (Apr 30 2020 at 14:25, on Zulip):

so, regarding PR #71495

pnkfelix (Apr 30 2020 at 14:25, on Zulip):

I think @simulacrum has separately noted that it is low-risk

simulacrum (Apr 30 2020 at 14:25, on Zulip):

yeah, well, it's a regression fix

simulacrum (Apr 30 2020 at 14:25, on Zulip):

(though that regression has hit stable)

pnkfelix (Apr 30 2020 at 14:26, on Zulip):

right, I was reviewing the state of that bug

pnkfelix (Apr 30 2020 at 14:26, on Zulip):

#71473 i think

pnkfelix (Apr 30 2020 at 14:26, on Zulip):

which has been noted as dupe of #68905

simulacrum (Apr 30 2020 at 14:26, on Zulip):

but generally I'd say that the fix is pretty minimal and fixes a regression -- seems like a good candidate

nikomatsakis (Apr 30 2020 at 14:26, on Zulip):

I don't know how to judge the stdarch but I'd be ok doing it

nikomatsakis (Apr 30 2020 at 14:27, on Zulip):

oh, I guess can click through to see the diffs

pnkfelix (Apr 30 2020 at 14:27, on Zulip):

does PR #71495 also fix #68905 ?

pnkfelix (Apr 30 2020 at 14:27, on Zulip):

or that was already fixed

Wesley Wiser (Apr 30 2020 at 14:27, on Zulip):

It's claimed to https://github.com/rust-lang/rust/issues/68905#issuecomment-601385193

pnkfelix (Apr 30 2020 at 14:27, on Zulip):

and this was remaining/overlooked work?

simulacrum (Apr 30 2020 at 14:27, on Zulip):

yeah overlooked

simulacrum (Apr 30 2020 at 14:28, on Zulip):

crater didn't catch it because the crate in question didn't compile anyway (assembler errors, iirc) and a more minimal stabilization was considered sufficient

simulacrum (Apr 30 2020 at 14:28, on Zulip):

well, no one argued strongly for more

pnkfelix (Apr 30 2020 at 14:28, on Zulip):

Ugh laptop died

pnkfelix (Apr 30 2020 at 14:29, on Zulip):

Um okay let’s say beta approved then

pnkfelix (Apr 30 2020 at 14:30, on Zulip):

Sorry I’m trying to bring up agenda on spare laptop now

Santiago Pastorino (Apr 30 2020 at 14:31, on Zulip):

let me help you a bit

pnkfelix (Apr 30 2020 at 14:31, on Zulip):

handing off to @Santiago Pastorino

Santiago Pastorino (Apr 30 2020 at 14:31, on Zulip):

so next is ....

Santiago Pastorino (Apr 30 2020 at 14:31, on Zulip):

Stable-nominations

Santiago Pastorino (Apr 30 2020 at 14:31, on Zulip):

we don't have stable nominations for T-compiler

Santiago Pastorino (Apr 30 2020 at 14:32, on Zulip):

but we do have two for T-libs

Santiago Pastorino (Apr 30 2020 at 14:32, on Zulip):

T-libs stable-nom 1/2: " "Update stdarch submodule" #71495 :back: / :hand:

Santiago Pastorino (Apr 30 2020 at 14:32, on Zulip):

well that one was also stable nominated

pnkfelix (Apr 30 2020 at 14:33, on Zulip):

Right we just approved it for beta

Santiago Pastorino (Apr 30 2020 at 14:33, on Zulip):

should it be approved for stable too?

pnkfelix (Apr 30 2020 at 14:33, on Zulip):

I suspect it is fine for stable too. Any objections?

Santiago Pastorino (Apr 30 2020 at 14:34, on Zulip):

ok, seems like this one is stable accepted

pnkfelix (Apr 30 2020 at 14:35, on Zulip):

okay I rebooted

Santiago Pastorino (Apr 30 2020 at 14:35, on Zulip):

bear with me because can see now how hard is Felix job here :)

Santiago Pastorino (Apr 30 2020 at 14:35, on Zulip):

T-libs stable-nom 2/2: - "avx512 support regression in 1.43" #71473 :back: / :hand:

Santiago Pastorino (Apr 30 2020 at 14:35, on Zulip):

handing back to you @pnkfelix ... pheww :)

nikomatsakis (Apr 30 2020 at 14:36, on Zulip):

wait, #71473 is an issue

pnkfelix (Apr 30 2020 at 14:36, on Zulip):

wait

pnkfelix (Apr 30 2020 at 14:36, on Zulip):

yeah

Wesley Wiser (Apr 30 2020 at 14:36, on Zulip):

I'm confused. What are we voting on? #71473 is an issue

pnkfelix (Apr 30 2020 at 14:36, on Zulip):

okay this was a hiccup

pnkfelix (Apr 30 2020 at 14:37, on Zulip):

but yeah

Wesley Wiser (Apr 30 2020 at 14:37, on Zulip):

I think this was nominated just to get discussion from T-libs which happened last week.

pnkfelix (Apr 30 2020 at 14:37, on Zulip):

we essentially just finished apprvoing this

Wesley Wiser (Apr 30 2020 at 14:37, on Zulip):

And was never un-nominated

pnkfelix (Apr 30 2020 at 14:38, on Zulip):

right, its possible that the stable-nominationed tag was added erroneously, or perhaps to get attention of T-libs, not sure

pnkfelix (Apr 30 2020 at 14:38, on Zulip):

in either case, we do not need to worry about approving this a second time

pnkfelix (Apr 30 2020 at 14:38, on Zulip):

okay, moving on

pnkfelix (Apr 30 2020 at 14:38, on Zulip):

PR's S-waiting-on-team

T-compiler S-waiting-on-team

pnkfelix (Apr 30 2020 at 14:38, on Zulip):

i.e. that's more of a general notice

pnkfelix (Apr 30 2020 at 14:40, on Zulip):

that that PR is on track to be merged, assuming it gets an r+ (@nagisa am I right in assuming that you, or perhaps @Hanna Kruppe , are going to take care of any further review and the r+?)

pnkfelix (Apr 30 2020 at 14:40, on Zulip):

next up

pnkfelix (Apr 30 2020 at 14:40, on Zulip):

Issues of Note

pnkfelix (Apr 30 2020 at 14:40, on Zulip):

Short Summary

There are 1 more P-critical issue and 1 less P-high issues in comparison with last week.

pnkfelix (Apr 30 2020 at 14:41, on Zulip):

wow two critical unassigned bugs

nikomatsakis (Apr 30 2020 at 14:41, on Zulip):

So @Santiago Pastorino and I were talking about him possibly fixing #71550 (a P-critical issue)

nikomatsakis (Apr 30 2020 at 14:41, on Zulip):

I was going to mention @Santiago Pastorino that if you want I could do a bit of digging with you later today

Santiago Pastorino (Apr 30 2020 at 14:41, on Zulip):

pnkfelix said:

wow two critical unassigned bugs

good news is that we've just released so we have time :)

Santiago Pastorino (Apr 30 2020 at 14:42, on Zulip):

nikomatsakis said:

I was going to mention Santiago Pastorino that if you want I could do a bit of digging with you later today

:+1:, let's assign that one to me

Santiago Pastorino (Apr 30 2020 at 14:42, on Zulip):

assigned to me

pnkfelix (Apr 30 2020 at 14:42, on Zulip):

is #71504 actually critical?

nikomatsakis (Apr 30 2020 at 14:42, on Zulip):

rust-analyser segfault with lto=thin, linker=lld-link #71504

nikomatsakis (Apr 30 2020 at 14:42, on Zulip):

ah, it's a segfault compiling rust-analyzer

Santiago Pastorino (Apr 30 2020 at 14:42, on Zulip):

yeah that was the pointer to P-critical

pnkfelix (Apr 30 2020 at 14:43, on Zulip):

but the segfault is from running lld itself?

pnkfelix (Apr 30 2020 at 14:43, on Zulip):

I don't know if we can do anything about that, if that's the case

Santiago Pastorino (Apr 30 2020 at 14:43, on Zulip):

rust-analyzer segfaulting but we discussed if it wasn't P-high, good to discuss with everyone now too :)

Wesley Wiser (Apr 30 2020 at 14:43, on Zulip):

No, the backtrace seems to be from running the result

nikomatsakis (Apr 30 2020 at 14:43, on Zulip):

So this is an lld (LLVM 10) bug, the first I encounter. So I guess this is out of rust-lang scope.

pnkfelix (Apr 30 2020 at 14:43, on Zulip):

/me looks again

nikomatsakis (Apr 30 2020 at 14:44, on Zulip):

I'm not sure I'd call it P-crticial, but it's .. complicated. e.g., @Jonas Schievink wrote:

Yes, embedded ARM targets use \[lld] by default. They're ELF targets though, and LLD's ELF backend is fairly reliable (I've only witnessed it corrupting debuginfo once, not cause crashes like this).

nikomatsakis (Apr 30 2020 at 14:45, on Zulip):

it'd be nice to at least report it upstream, if it's truly an lld bug

pnkfelix (Apr 30 2020 at 14:45, on Zulip):

so we have two questions to address: 1. is this within our scope to address, and 2. if so, is it critical, or merely P-high (perhaps)

pnkfelix (Apr 30 2020 at 14:45, on Zulip):

LLVM ice breakers have already been pinged on it

Wesley Wiser (Apr 30 2020 at 14:45, on Zulip):

I think it also needs the I-unsound label re-applied. I'm not sure how this situation is different than other LLVM related unsoundness issues.

Santiago Pastorino (Apr 30 2020 at 14:45, on Zulip):

I guess given the latest comments seems more like P-high than P-critical

pnkfelix (Apr 30 2020 at 14:46, on Zulip):

I guess we need to reduce it further to properly evaluate the answers to my two questions

pnkfelix (Apr 30 2020 at 14:46, on Zulip):

lets downgrade to P-high (unless someone here wants to argue for P-critical)

pnkfelix (Apr 30 2020 at 14:47, on Zulip):

and other than that, yeah, it may need I-unsound explosion-icon readded

nikomatsakis (Apr 30 2020 at 14:47, on Zulip):

seems right

pnkfelix (Apr 30 2020 at 14:47, on Zulip):

/me wonders if they would be able to get away with renaming that back to I-unsound

simulacrum (Apr 30 2020 at 14:48, on Zulip):

I'd not mind :)

I think segfaults are presumably not unsound?

simulacrum (Apr 30 2020 at 14:48, on Zulip):

if they're at link time

simulacrum (Apr 30 2020 at 14:48, on Zulip):

though I'm still not clear on that

pnkfelix (Apr 30 2020 at 14:48, on Zulip):

you mean if they are a result of linker error?

pnkfelix (Apr 30 2020 at 14:49, on Zulip):

the segfault, it seems, is not at link time; I was incorrect about that, according to the posted back trace

Wesley Wiser (Apr 30 2020 at 14:49, on Zulip):

This comment suggests the segfault happens at run time.

simulacrum (Apr 30 2020 at 14:49, on Zulip):

hm, so one other thing to check - potentially, IIRC, thin LTO means that the linker is running that LTO

simulacrum (Apr 30 2020 at 14:49, on Zulip):

however if LLVM we used to generate the bitcode and the linker's LLVM are different, well, that could presumably be a problem

pnkfelix (Apr 30 2020 at 14:49, on Zulip):

oh interesting

pnkfelix (Apr 30 2020 at 14:50, on Zulip):

maybe I will try to look into this later, but that may be tricky if this only reproduces on Windows

pnkfelix (Apr 30 2020 at 14:50, on Zulip):

@Wesley Wiser you use Windows, right? Do you have spare cycles to check if this at least reproduces for you locally?

pnkfelix (Apr 30 2020 at 14:51, on Zulip):

anyway

tmandry (Apr 30 2020 at 14:51, on Zulip):

fyi, we use lld on fuchsia with LLVM version skew like that, and haven't encountered problems like the one @simulacrum mentions

Wesley Wiser (Apr 30 2020 at 14:51, on Zulip):

Oof that's what happens when you volunteer :laughing:

Wesley Wiser (Apr 30 2020 at 14:51, on Zulip):

Yeah, I can definitely try to repro it :slight_smile:

pnkfelix (Apr 30 2020 at 14:51, on Zulip):

@Wesley Wiser its no problem if you can't spare the time (as a human or of your machine)

simulacrum (Apr 30 2020 at 14:51, on Zulip):

@tmandry hm, interesting. it might also be dependent on something else -- I don't really know how stable etc llvm's bitcode is wrt to thinlto

Wesley Wiser (Apr 30 2020 at 14:52, on Zulip):

No, I've got time. Just joking.

pnkfelix (Apr 30 2020 at 14:52, on Zulip):

we really do need to make an ICE-breakers Window-breakers

pnkfelix (Apr 30 2020 at 14:52, on Zulip):

anyway

pnkfelix (Apr 30 2020 at 14:52, on Zulip):

just a few more things

pnkfelix (Apr 30 2020 at 14:52, on Zulip):

two nominated issues

pnkfelix (Apr 30 2020 at 14:52, on Zulip):

we already touched on #71550

eddyb (Apr 30 2020 at 14:52, on Zulip):

/me idly wonders if you can run lld-link on Linux...

pnkfelix (Apr 30 2020 at 14:52, on Zulip):

(and I guess @Santiago Pastorino is going to be looking at #71550 later today)

pnkfelix (Apr 30 2020 at 14:53, on Zulip):

and the other nominated issue was (emphasis) #71416

pnkfelix (Apr 30 2020 at 14:53, on Zulip):

but I forked off some fresh issues for that

Santiago Pastorino (Apr 30 2020 at 14:53, on Zulip):

I've assigned those to myself as follow up of the original issue

pnkfelix (Apr 30 2020 at 14:53, on Zulip):

I did want to check though: @Santiago Pastorino and I tentatively decided to make "Dynamically select alignment of a dyn Trait local value" #71695 a P-medium ticket

Santiago Pastorino (Apr 30 2020 at 14:53, on Zulip):

if someone really wants to jump there or something feel free :)

pnkfelix (Apr 30 2020 at 14:54, on Zulip):

and I was curious if anyone had feedback on how high priority it might be to finish implementing that feature

pnkfelix (Apr 30 2020 at 14:54, on Zulip):

(like, correctly)

pnkfelix (Apr 30 2020 at 14:54, on Zulip):

but you don't have to provide such feedback synchronously

pnkfelix (Apr 30 2020 at 14:55, on Zulip):

feel free to post it on the issue or in a zulip topic

pnkfelix (Apr 30 2020 at 14:55, on Zulip):

finally

pnkfelix (Apr 30 2020 at 14:55, on Zulip):

WG checkins

pnkfelix (Apr 30 2020 at 14:55, on Zulip):

WG-Polymorphization by @davidtwco:

I can't remember where the polymorphisation work was last time I gave an update at the meeting, so to remind everyone, the polymorphisation working group is for tracking my master's project - implementing an analysis that will detect when generic parameters are unused, and then reducing monomorphisation as a result.

#69749 has a working implementation of polymorphisation (I've paused working on it until my exams are over), which we've run perf on and gotten mixed results - there are some interesting interactions with LTO on one benchmark configuration, and some cases see 3-5% improvements, but some are worse-off (normally by 1-2%). There's probably some room for improvement yet.

pnkfelix (Apr 30 2020 at 14:55, on Zulip):

and

pnkfelix (Apr 30 2020 at 14:55, on Zulip):

WG-prioritization by @spastorino:

This is the first checkin from WG Prioritization.

pnkfelix (Apr 30 2020 at 14:56, on Zulip):

oh right, gotta put asterisks around peoples names when you paste them into zulip, hmm...

nikomatsakis (Apr 30 2020 at 14:56, on Zulip):

I would like to take this moment to raise the question of

nikomatsakis (Apr 30 2020 at 14:56, on Zulip):

how to proceed with @davidtwco's work

nikomatsakis (Apr 30 2020 at 14:56, on Zulip):

Personally I think we should land it

nikomatsakis (Apr 30 2020 at 14:56, on Zulip):

But I'm not sure what we should do before landing it :)

Santiago Pastorino (Apr 30 2020 at 14:56, on Zulip):

pnkfelix said:

oh right, gotta put asterisks around peoples names when you paste them into zulip, hmm...

:+1:, will add that to the template :)

nikomatsakis (Apr 30 2020 at 14:56, on Zulip):

And I could imagine landing it behind an opt-level flag or something, if we think it's not there yet

pnkfelix (Apr 30 2020 at 14:56, on Zulip):

nikomatsakis said:

Personally I think we should land it

the main issue is that the performance "wins" are not what was expected

pnkfelix (Apr 30 2020 at 14:56, on Zulip):

right?

nikomatsakis (Apr 30 2020 at 14:57, on Zulip):

Correct

eddyb (Apr 30 2020 at 14:57, on Zulip):

did we measure code size at all?

nikomatsakis (Apr 30 2020 at 14:57, on Zulip):

I'm not 100% sure what was expected

simulacrum (Apr 30 2020 at 14:57, on Zulip):

compile time, that is, right?

eddyb (Apr 30 2020 at 14:57, on Zulip):

and also unoptimized builds

nikomatsakis (Apr 30 2020 at 14:57, on Zulip):

but they're not overwhelming

pnkfelix (Apr 30 2020 at 14:57, on Zulip):

eddyb said:

did we measure code size at all?

I asked them to in my feedback on the thesis

nikomatsakis (Apr 30 2020 at 14:57, on Zulip):

I don't know, but I think coming up with a list of measurements we'd like is a good idea

pnkfelix (Apr 30 2020 at 14:57, on Zulip):

but that was more of a warning "your committee might want this"

eddyb (Apr 30 2020 at 14:57, on Zulip):

all of the slowdowns appear to be (without further investigation) from LLVM being able to do more

nikomatsakis (Apr 30 2020 at 14:58, on Zulip):

I could imagine having a design meeting to discuss this a bit

eddyb (Apr 30 2020 at 14:58, on Zulip):

(not on the rustc side)

pnkfelix (Apr 30 2020 at 14:58, on Zulip):

eddyb said:

all of the slowdowns appear to be (without further investigation) from LLVM being able to do more

as in, LLVM is producing better final code?

pnkfelix (Apr 30 2020 at 14:58, on Zulip):

and thus compilation is slower?

eddyb (Apr 30 2020 at 14:58, on Zulip):

unclear, but definitely spending more time on it

nikomatsakis (Apr 30 2020 at 14:58, on Zulip):

and in particular I'd like to (ideally) motivate folks to do more follow-up work (or at least discuss what kind of follow-up work we might do)

nikomatsakis (Apr 30 2020 at 14:58, on Zulip):

that's interesting, @eddyb

tmandry (Apr 30 2020 at 14:59, on Zulip):

I suspect you would get some code size wins and that matters a lot in embedded use cases

pnkfelix (Apr 30 2020 at 14:59, on Zulip):

I think it sounds like we definitely do not want to throw this work away

nikomatsakis (Apr 30 2020 at 14:59, on Zulip):

anyway I have to run in a bit but I do think we should, well, decide how to decide? then decide? not let it sit in limbo, in short

nikomatsakis (Apr 30 2020 at 14:59, on Zulip):

pnkfelix said:

I think it sounds like we definitely do not want to throw this work away

this too!

pnkfelix (Apr 30 2020 at 14:59, on Zulip):

is it worth a design meeting?

Wesley Wiser (Apr 30 2020 at 14:59, on Zulip):

One other thing the MIR Opt wg has seen is that changes to MIR can cause the cgu partitioning algorithm to put functions in different modules due to code size differences. That can have positive and negative effects on the incremental tests depending on whether or not you get lucky.

nikomatsakis (Apr 30 2020 at 14:59, on Zulip):

which is my main point to why I think we should land it

pnkfelix (Apr 30 2020 at 14:59, on Zulip):

maybe not worth a design meeting, at least not yet

nikomatsakis (Apr 30 2020 at 14:59, on Zulip):

@Wesley Wiser I wonder how much the "mir opt" folks would want to follow-up on this work

nikomatsakis (Apr 30 2020 at 15:00, on Zulip):

I think it definitely could be worth many design meetings, but it'd be good to clarify the goal thereof

Wesley Wiser (Apr 30 2020 at 15:00, on Zulip):

We just opened a compiler team planning meeting request for that this morning :p

pnkfelix (Apr 30 2020 at 15:00, on Zulip):

Wesley Wiser said:

One other thing the MIR Opt wg has seen is that changes to MIR can cause the cgu partitioning algorithm to put functions in different modules due to code size differences. That can have positive and negative effects on the incremental tests depending on whether or not you get lucky.

I have wondered about this, and whether it is something we can/should try to make more predictable

eddyb (Apr 30 2020 at 15:00, on Zulip):

another interesting thing is that this barely scratches the surface, and there are some easy (and some harder due to lack of necessary infra in codegen) ways to remove even more monomorphizations

davidtwco (Apr 30 2020 at 15:00, on Zulip):

In three weeks today I’ll be done with exams and can get back to working on this, but if we want to land this sooner then I’m happy for someone to rebase it and polish it off. Keep me in the loop because I’m still interested in seeing it through.

pnkfelix (Apr 30 2020 at 15:00, on Zulip):

just in terms of not having e.g. additions and removals of impl { } cause such different cgu partitionings

pnkfelix (Apr 30 2020 at 15:01, on Zulip):

well the hour is up

eddyb (Apr 30 2020 at 15:01, on Zulip):

e.g. of something the initial implementation doesn't detect: Vec::<T>::len doesn't depend on T (but everything during its codegen would need to know T: Sized, i.e. have a valid ParamEnv)

pnkfelix (Apr 30 2020 at 15:01, on Zulip):

I think the answer is that we are not ready to land @davidtwco 's work as is, but we should have follow-up discussion about how to do so

pnkfelix (Apr 30 2020 at 15:01, on Zulip):

can maybe the WG-mir-opt take charge on that? does that make sense?

pnkfelix (Apr 30 2020 at 15:02, on Zulip):

(we could even just decide to wait until @davidtwco is back from exams before we try to do anything with it. I doubt we need to rush to land it, right?)

davidtwco (Apr 30 2020 at 15:02, on Zulip):

I think it would make sense to fold the work into wg-mir-opt and retire the dedicated working group now.

oli (Apr 30 2020 at 15:02, on Zulip):

does make sense, but I don't know where to take the time from to actually give this the attention it deserves

eddyb (Apr 30 2020 at 15:03, on Zulip):

I think waiting is fine, I'm not sure I'll even get to take another look at it in the next couple weeks

Wesley Wiser (Apr 30 2020 at 15:03, on Zulip):

I don't think there's an urgent rush and I would be happy to help @davidtwco where I can

pnkfelix (Apr 30 2020 at 15:03, on Zulip):

okay that's great

pnkfelix (Apr 30 2020 at 15:03, on Zulip):

Also, one more thing

Santiago Pastorino (Apr 30 2020 at 15:03, on Zulip):

may be able to spend some time on it, let's continue discussing in #t-compiler/wg-mir-opt

pnkfelix (Apr 30 2020 at 15:03, on Zulip):

Thanks again to @WG-prioritization for working yesterday to establish the agenda for today's meeting

pnkfelix (Apr 30 2020 at 15:04, on Zulip):

and for all their work on making an asynchronous process for prioritization

pnkfelix (Apr 30 2020 at 15:04, on Zulip):

I don't know how many people are watching the t-compiler/wg-prioritization stream

pnkfelix (Apr 30 2020 at 15:04, on Zulip):

but I think it serves as an interesting case study

LeSeulArtichaut (Apr 30 2020 at 15:04, on Zulip):

Staring at it xD

pnkfelix (Apr 30 2020 at 15:05, on Zulip):

in how to move from a high-bus factor individually-driven process to a ... "low" bus factor group-driven one

pnkfelix (Apr 30 2020 at 15:05, on Zulip):

time will tell if it pays off or not

pnkfelix (Apr 30 2020 at 15:05, on Zulip):

well, that's not fair

pnkfelix (Apr 30 2020 at 15:05, on Zulip):

its definitely paid off, for me

pnkfelix (Apr 30 2020 at 15:06, on Zulip):

but @Santiago Pastorino made a good point to me earlier to

pnkfelix (Apr 30 2020 at 15:06, on Zulip):

today

pnkfelix (Apr 30 2020 at 15:06, on Zulip):

which is: The time that group is putting in

pnkfelix (Apr 30 2020 at 15:06, on Zulip):

is all about making this meeting useful

pnkfelix (Apr 30 2020 at 15:06, on Zulip):

and efficient

pnkfelix (Apr 30 2020 at 15:06, on Zulip):

so, we should all be reflecting on where this meeting fails to achieve those goals

pnkfelix (Apr 30 2020 at 15:07, on Zulip):

(thus my aforementioned plans to try to reduce the amount of time we spend discussing low-risk beta backports)

pnkfelix (Apr 30 2020 at 15:07, on Zulip):

anyway

pnkfelix (Apr 30 2020 at 15:07, on Zulip):

I digress

pnkfelix (Apr 30 2020 at 15:07, on Zulip):

Thanks to everyone in @T-compiler/meeting for attending! This was a great week, you are all great. Stay safe, stay healthy.

pnkfelix (Apr 30 2020 at 15:10, on Zulip):

Esteban Küber said:

Btw, re the doc backport, I proposed it to avoid the wrong documentation ending up in the public facing website.

hey @Esteban Küber , do you want me to leave the doc backport tagged as beta-nominated, and we can discuss again next week?

Esteban Küber (Apr 30 2020 at 15:10, on Zulip):

Sure

Esteban Küber (Apr 30 2020 at 15:10, on Zulip):

As you prefer

pnkfelix (Apr 30 2020 at 15:11, on Zulip):

(or maybe i'll just approve it, based on the argument you gave. The basic issue is that every error shows up in our public index, regardless of whether that error is visible in stable code or not, right?)

Esteban Küber (Apr 30 2020 at 15:11, on Zulip):

Correct

pnkfelix (Apr 30 2020 at 15:11, on Zulip):

its an interesting stability issue.

Esteban Küber (Apr 30 2020 at 15:12, on Zulip):

It is, and a consequence of mixing docs and code, which is not shared by the book for example, only affects the index

pnkfelix (Apr 30 2020 at 15:12, on Zulip):

and so the various Web Search Engines (google, bing, duckduckgo, ...) all traverse that index and so would get the bad data in the database that we assume people will be querying?

Esteban Küber (Apr 30 2020 at 15:27, on Zulip):

Not only that, some people use the index but don't use the rustc output for error codes

Esteban Küber (Apr 30 2020 at 15:27, on Zulip):

I ran a small poll and it was evenly divided

Esteban Küber (Apr 30 2020 at 15:27, on Zulip):

Between people who didn't use either at all, used both, and used one or the other

LeSeulArtichaut (Apr 30 2020 at 23:02, on Zulip):

Is it me or #71488 wasn’t labeled as beta-accepted?

pnkfelix (May 01 2020 at 01:42, on Zulip):

sorry I got distracted and didn't finish going through the meeting results

pnkfelix (May 01 2020 at 01:42, on Zulip):

I usually try to traverse it right after the meeting (since I find that trying to update the issues during the meeting slows it down.)

pnkfelix (May 01 2020 at 01:43, on Zulip):

(and also because I like to link to the zulip-archive.rust-lang.org, which has a bit of a delay to update)

Wesley Wiser (May 01 2020 at 15:00, on Zulip):

pnkfelix said:

Wesley Wiser you use Windows, right? Do you have spare cycles to check if this at least reproduces for you locally?

@pnkfelix I was able to repro on Windows: https://github.com/rust-lang/rust/issues/71504#issuecomment-622422103

Wesley Wiser (May 01 2020 at 15:05, on Zulip):

Let me know if there's anything more I can help with. This kind of issue is pretty far outside what I know how to debug but I've very interested in learning!

pnkfelix (May 01 2020 at 15:19, on Zulip):

The recipe for reproduction was all I wanted, thanks @Wesley Wiser !!

Last update: Jun 04 2020 at 18:35UTC