Stream: t-compiler

Topic: PlaceBase removal


Santiago Pastorino (Dec 13 2019 at 13:57, on Zulip):

@oli this https://github.com/rust-lang/rust/pull/67000 is now ready

Santiago Pastorino (Dec 13 2019 at 13:57, on Zulip):

it sits on top of https://github.com/rust-lang/rust/pull/67192

Santiago Pastorino (Dec 13 2019 at 13:58, on Zulip):

which you were discussing with @RalfJ

Santiago Pastorino (Dec 13 2019 at 13:59, on Zulip):

I need to check that PR again but at some point saw that @RalfJ was asking for some motivation about the PR, well if it helps a bit #67000 is part of the motivation :smile:

oli (Dec 13 2019 at 14:05, on Zulip):

So the problem with #67000 is that since we now make all promoteds essentially let tmp = promoted; &tmp, the addr-of-zst-promoted-becomes-integer-pointer logic in codegen isn't triggered anymore, thus causing test failures where we compare the address &() with 1. While we could fix this just in codegen, this would severely complicate codegen, and also cause the weird situation where assert!(&() as *const () as usize == 1) fails at compile-time but works at runtime

RalfJ (Dec 22 2019 at 16:35, on Zulip):

I am questioning those tests, Is there an RFC/FCP that we guarantee the address of temporary 1-ZSTs to be 1?

oli (Dec 22 2019 at 19:32, on Zulip):

nope

oli (Dec 22 2019 at 19:32, on Zulip):

should we just brick them all?

nikomatsakis (Dec 23 2019 at 11:42, on Zulip):

Hmm, interesting

nikomatsakis (Dec 23 2019 at 11:43, on Zulip):

I'm trying to remember. I certainly don't recall guaranteeing the address of a ZST to be anything other than "not null"

oli (Dec 23 2019 at 11:47, on Zulip):

we don't afaict, but we have done some work to make the addresses whatever std::ptr::dangling returns: https://github.com/rust-lang/rust/pull/62487

nikomatsakis (Dec 23 2019 at 12:09, on Zulip):

Yeah, I had a vague memory of that

nikomatsakis (Dec 23 2019 at 12:09, on Zulip):

We should I guess clarify exactly what we are specifying; there may be de facto reliance on dangling

nikomatsakis (Dec 23 2019 at 12:10, on Zulip):

( cc @scottmcm )

nikomatsakis (Dec 23 2019 at 12:10, on Zulip):

but I didn't interpret that PR as any form of "guarantee" for sure

nikomatsakis (Dec 23 2019 at 12:10, on Zulip):

I didnt' quite understand where the various perf/compiler wins came from there, I guess maybe it had more to do with however we were compiling things before..?

oli (Dec 23 2019 at 13:10, on Zulip):

the perf wins came from llvm not creating allocations

oli (Dec 23 2019 at 13:14, on Zulip):

I don't think any code can be relying on it, because let x: [i32; 0] = []; let y = &[x] will not give y a dangling address

Last update: Jan 21 2020 at 09:45UTC