[MIR] Add Storage{Live,Dead} statements to emit llvm.lifetime.{start,end}.

[eddyb]

Storage live ranges are tracked for all MIR variables and temporaries with a drop scope.
StorageLive is lowered to llvm.lifetime.start and StorageDead to llvm.lifetime.end.

There are some improvements possible here, such as:

• pack multiple storage liveness statements by using the index of first local + u64 bitset
• enforce that locals are not directly accessed outside their storage live range
• shrink storage live ranges for never-borrowed locals to initialization -> last use
• emit storage liveness statements for all temporaries
  • however, the remaining ones are always SSA immediates, so they'd be noop in MIR trans
  • could have a flag on the temporary that its storage is irrelevant (a la C's old register)
    • would also deny borrows if necessary
    • this seems like an overcompliation and with packing & optimizations it may be pointless

Even in the current state, it helps stage2 rustc compile boiler without overflowing (see #35408).

A later addition fixes#26764 and closes#27372 by emitting .section directives for dylib metadata to avoid them being allocated into memory or read as .note. For this PR, those bugs were tripping valgrind.

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[nagisa]

Make a helper function in cfg, since you’re constructing this multiple times manually.

This should become this.cfg.push_storage_live(source_info, temp);

[arielb1]

Test please

[nikomatsakis]

Hmm, should this be restricted to base lvalues or something like that? Meh, I guess it's ok to use Lvalue<'tcx> here.

[eddyb]

Local would be great, but even then, it would not be applicable to ReturnPointer or args.

[nikomatsakis]

Test please

Seems like a good use for @scottcarr's MIR testing framework.

[scottcarr]

Is there some way to refactor the arms? The only difference is End.call or Start.call, right?

EDIT: (I edited my original note which said "why not call lvalue_trans?" -- which we do not need)

[eddyb]

We need to do nothing if the local is not an Lvalue.
Using a method taking lvalue and the base::Lifetime would work, yeah.

[nikomatsakis]

OK so @eddyb convinced me that most of my concerns were moot. r=me modulo the following:

• needs a test
• need a few more comments
• make things DRY, as @scottcarr suggested
• maybe remove storage from "constant MIR"?
• super minor nits (1, 2) to address if you agree

[eddyb]

@bors r=nikomatsakis p=1 (if this gets into the nightly, it may fix a couple crates)

[bors]

📌 Commit 7def9f5 has been approved by nikomatsakis

[bors]

⌛ Testing commit 7def9f5 with merge a5973b6...

[bors]

💔 Test failed - auto-linux-64-opt

[nikomatsakis]

Failures are valgrind failures:

---- [run-pass-valgrind] run-pass-valgrind/coerce-match-calls.rs stdout ----
error: test run failed!
status: exit code: 100
command: /usr/bin/valgrind --error-exitcode=100 --fair-sched=try --quiet --soname-synonyms=somalloc=NONE --suppressions=/buildslave/rust-buildbot/slave/auto-linux-64-opt/build/src/etc/x86.supp --tool=memcheck --leak-check=full x86_64-unknown-linux-gnu/test/run-pass-valgrind/coerce-match-calls.stage2-x86_64-unknown-linux-gnu
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
==20600== Syscall param read(buf) points to unaddressable byte(s)
==20600== at 0x401B177: read (syscall-template.S:84)
==20600== by 0x40059FF: open_verify.constprop.7 (dl-load.c:1949)
==20600== by 0x4005CD9: open_path (dl-load.c:2066)
==20600== by 0x4008BE0: _dl_map_object (dl-load.c:2307)
==20600== by 0x400D9D1: openaux (dl-deps.c:63)
==20600== by 0x4010393: _dl_catch_error (dl-error.c:187)
==20600== by 0x400E011: _dl_map_object_deps (dl-deps.c:254)
==20600== by 0x40034F9: dl_main (rtld.c:1610)
==20600== by 0x4019461: _dl_sysdep_start (dl-sysdep.c:249)
==20600== by 0x4004E79: _dl_start_final (rtld.c:307)
==20600== by 0x4004E79: _dl_start (rtld.c:413)
==20600== by 0x4000CC7: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==20600== Address 0xffee10a00 is on thread 1's stack
==20600== in frame #1, created by open_verify.constprop.7 (dl-load.c:1695)
==20600== ------------------------------------------

Could be real!

[eddyb]

@nikomatsakis I pinged @alexcrichton but I don't think he had time to look over them yet.
AFAICT, those are in rtld, which could only be a problem at the end of execution, if we've ruined any rtld state - but the stack trace makes me believe it's actually at the start of execution.

[eddyb]

@bors retry (hoping this is spurious)

[eddyb]

@bors p=0

[bors]

☔ The latest upstream changes (presumably #35348) made this pull request unmergeable. Please resolve the merge conflicts.

[eddyb]

@bors r=nikomatsakis

[bors]

📌 Commit 02aec40 has been approved by nikomatsakis

[bors]

⌛ Testing commit 02aec40 with merge 4d03edd...

[bors]

💔 Test failed - auto-linux-64-opt

[eddyb]

I can't reproduce don't have valgrind locally at all 😕.

[eddyb]

Argh #26764 strikes again, this time libstd's .note.rustc section being too large for just one rtld function to alloca at once, according to valgrind.

[eddyb]

@bors r=nikomatsakis

[bors]

📌 Commit 1bb1444 has been approved by nikomatsakis

[eddyb]

@bors p=2

[bors]

⌛ Testing commit 1bb1444 with merge 1d5b758...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-no-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-no-mir, auto-win-msvc-64-opt-rustbuild
Approved by: nikomatsakis
Pushing 1d5b758 to master...

[cuviper]

I don't know about the rest, but thanks for the incidental .note cleanup! 😄