Stream: t-lang/wg-unsafe-code-guidelines

Topic: homogeneous aggregates


gnzlbg (Dec 05 2019 at 19:53, on Zulip):

@rkruppe the PR ucg#220 only provides the guarantee for tuples, tuple structs and arrays

gnzlbg (Dec 05 2019 at 19:54, on Zulip):

resolving ucg#36 as this guarantee not being provided for structs

gnzlbg (Dec 05 2019 at 19:54, on Zulip):

I personally would prefer to just say something like:

All homogeneous aggregates of the same repr and length share the same layout.

rkruppe (Dec 05 2019 at 19:55, on Zulip):

I see nothing about tuple structs in that diff

gnzlbg (Dec 05 2019 at 19:55, on Zulip):

Tuples are defined as tuple structs in libcore IIRC

rkruppe (Dec 05 2019 at 19:55, on Zulip):

They are not, but that doesn't relate to what I said anyway

rkruppe (Dec 05 2019 at 19:56, on Zulip):

The diff only provides a guarantee for tuples, not for tuple structs

gnzlbg (Dec 05 2019 at 19:56, on Zulip):

an anonymous tuple type (T1..Tn) of arity N is laid out "as if" there were a corresponding tuple struct declared in libcore

rkruppe (Dec 05 2019 at 19:56, on Zulip):

Oh that's what you mean

rkruppe (Dec 05 2019 at 19:57, on Zulip):

But still, the diff only provides a guarantee for tuples, not tuple structs in general

gnzlbg (Dec 05 2019 at 19:57, on Zulip):

So if the layout of arrays and anonymous tuples match, so does the layout of arrays and tuple structs

gnzlbg (Dec 05 2019 at 19:57, on Zulip):

otherwise, anonymous tuples cannot be laid out as tuple structs anymore

rkruppe (Dec 05 2019 at 19:58, on Zulip):

That might mean your diff is contradictory as is but it still doesn't say anything about tuple structs

gnzlbg (Dec 05 2019 at 19:58, on Zulip):

I could add "homogeneous tuples and homogeneous tuple structs" to make that clearer

gnzlbg (Dec 05 2019 at 19:58, on Zulip):

My diff doesn't say anything about tuple structs because it doesn't have to

gnzlbg (Dec 05 2019 at 19:58, on Zulip):

We have already specified that the layout of anonymous tuples and tuple structs is exactly the same

gnzlbg (Dec 05 2019 at 19:58, on Zulip):

Or at least, that's how I understood that sentence.

gnzlbg (Dec 05 2019 at 19:59, on Zulip):

Maybe that wasn't the intent, and two identically defined tuple structs are allowed to have different layouts? No idea.

rkruppe (Dec 05 2019 at 20:00, on Zulip):

It says tuples are like particular tuple structs, but tuple struct layout is still generally not defined, so structurally identical tuple structs can have different layout

gnzlbg (Dec 05 2019 at 20:01, on Zulip):

Ah, ok.

rkruppe (Dec 05 2019 at 20:01, on Zulip):

But none of what you propose has any consensus anyway

gnzlbg (Dec 05 2019 at 20:01, on Zulip):

Then I think we should just say something about homogeneous aggregates in general, because if I say something about tuple structs, then I'm also saying something about structs.

gnzlbg (Dec 05 2019 at 20:01, on Zulip):

(tuple structs are just structs with fields named after the integers)

rkruppe (Dec 05 2019 at 20:03, on Zulip):

I really don't want to open that controversial discussion again. It's not even the current active topic and I don't expect we'd get consensus this time around

gnzlbg (Dec 05 2019 at 20:09, on Zulip):

What is the controversy in #36 ?

gnzlbg (Dec 05 2019 at 20:10, on Zulip):

The main arguments against guaranteeing the layout of homogeneous aggregates was PGO or raising the alignment, but it was proposed that doing that could be done using specific repr attributes (e.g. repr(opt)) or similar, which IMO makes sense.

rkruppe (Dec 05 2019 at 20:12, on Zulip):

With all due respect for your personal preferences, we've had plenty of comments explicitly not being convinced by that proposal since it was made

rkruppe (Dec 05 2019 at 20:15, on Zulip):

And fwiw we also haven't made layout of other structs "deterministic w.r.t. field types"/structural because of the exact same concerns.

gnzlbg (Dec 05 2019 at 20:22, on Zulip):

The only concerns I see broken by the definition are:

gnzlbg (Dec 05 2019 at 20:23, on Zulip):

Are there any others ?

rkruppe (Dec 05 2019 at 20:26, on Zulip):

There are others but what you've listed is already plenty

rkruppe (Dec 05 2019 at 20:27, on Zulip):

By that I mean there is absolutely no basis for nailing down their layout atm, it will require more consensus building, and IMO this is absolutely not a good use of anyone's time at the moment

gnzlbg (Dec 05 2019 at 20:28, on Zulip):

Using PGO to avoid false-sharing is horrible, defining what homogeneous means is trivial, and for there to be a possible performance gap between homogeneous and heterogeneous aggregates somebody would need to mention an optimization that would be possible for heterogeneous aggregates that wouldn't be possible for homogeneous ones.

gnzlbg (Dec 05 2019 at 20:29, on Zulip):

The only one that has been mentioned is field-reordering.

rkruppe (Dec 05 2019 at 20:49, on Zulip):

That's not true (just off the top of my head there's field randomization and raising alignment) but more importantly, as I said before, if we let things like hypothetical possibility of PGO stop us from nailing down layout of general structs further (and that's the status quo, like it or not!) then it should also stop us from nailing down layout of homogeneous structs specifically, because there's no reason PGO would apply any less to those structs.

gnzlbg (Dec 05 2019 at 21:31, on Zulip):

I've replied to the issue with a summary

gnzlbg (Dec 05 2019 at 21:32, on Zulip):

If we guarantee the field order for these types, then code that relies on that is correct, so I wasn't sure what the point of field randomization would be (it would break correct code).

gnzlbg (Dec 05 2019 at 21:33, on Zulip):

Raising the alignment up to the size is allowed. Raising the alignment beyond the size has the consequence of increasing the size of the aggregate.

gnzlbg (Dec 05 2019 at 21:34, on Zulip):

That might be worth it in some cases, but can be done with #[repr(align())], and instead of doing this silently, e.g., with PGO, we could just tell the user "If you want faster code add repr(align(N)) here.

gnzlbg (Dec 05 2019 at 21:36, on Zulip):

Field re-ordering due to PGO still sounds to me like the best reason for not doing this, and I get the point that if it is not worth it for homogeneous struct, why would it be worth it for heterogeneous ones?

rkruppe (Dec 05 2019 at 21:37, on Zulip):

Jesus, are you still at it? I would like more layout guarantees too but why the hell dig this specific thing up now? Either nobody bites and we don't get discussion and consensus, in which case all of this is a waste of time, or there's a huge discussion again and that is really not what UCG time should be spent on when even the current active topic (validity) is in limbo. Even assuming we end up with consensus.

gnzlbg (Dec 05 2019 at 21:39, on Zulip):

I would like more layout guarantees too but why the hell dig this specific thing up now?

I was looking into safe transmutes, and ran into transmuting anonymous tuples into anything is unsound.

Lokathor (Dec 05 2019 at 21:41, on Zulip):

I think it's sufficient for tuples to be unspecified because anyone who cares can make a struct with repr(C) on it

rkruppe (Dec 05 2019 at 21:42, on Zulip):

That explains how the topic got your attention again, but not why it should be pursued so aggressively now. Nothing about any safe transmute design hinges on tuples specifically, some trait impls get added if/when tuple layout is defined and not having those impls affects nothing except the ability to transmute tuples (which is also impossible to do unsafely for lack of layout guarantees, so it's not a safe-transmute-specific problem)

gnzlbg (Dec 05 2019 at 21:43, on Zulip):

hypothetical possibility of PGO stop us from nailing down layout of general structs further (and that's the status quo, like it or not!) then it should also stop us from nailing down layout of homogeneous structs specifically, because there's no reason PGO would apply any less to those structs.

Beyond PGO, the layout of heterogeneous aggregates is also blocked on things like variadics, e.g., do we want to support slicing &(A, B, C) into &(A, b) and &(B, C) )? Since that limits whether we can re-order the fields to reduce padding or not.

rkruppe (Dec 05 2019 at 21:46, on Zulip):

I'm opting out now (and muting this thread so I stick to it), I think I've made clear that I consider spending any time on this topic at this time is ill-advised and I've spent entirely too much time on it already

Last update: May 26 2020 at 10:40UTC