struct field reordering and optimization

[ahicks92]

This is work in progress. The goal is to divorce the order of fields in source code from the order of fields in the LLVM IR, then optimize structs (and tuples/enum variants)by always ordering fields from least to most aligned. It does not work yet. I intend to check compiler memory usage as a benchmark, and a crater run will probably be required.

I don't know enough of the compiler to complete this work unaided. If you see places that still need updating, please mention them. The only one I know of currently is debuginfo, which I'm putting off intentionally until a bit later.

r? @eddyb

[eddyb]

You can probably move the whole body of fill_in_fields into fn new. Also maybe rename it to from_fields.

EDIT: Oh is it because of if fields.len() == 0 {return Ok(())}; below?

[ahicks92]

I didn't think of it that way, but you're right in that that's a good reason. I just preferred to separate the overview from the steps, if you will.

[eddyb]

The problem is that this function shouldn't be possible to call at all, this is really outlining, and there's no usefulness gained by having self - that is, I'd expect the Struct be created at the very end.

[eddyb]

Can use let i = path.last_mut().unwrap(); and then read and write *i.

[ahicks92]

That wouldn't be an improvement because the borrow lasts too long. It would have to be wrapped in braces and indented further or I'd have to use mem::forget. We can't push the 0 onto the Vec while i exists.

[eddyb]

Oh whoops. Only braces would work, btw, borrows can't even be terminated manually.

[eddyb]

None of these changes seem to be really needed - or are you planning to move the ZSTs here?

[ahicks92]

This is because we can no longer iterate over the fields in order until after we have the struct.

[eddyb]

To have the increasing order offsets (instead of declaration order - is it really necessary?) you need to rename the field to permuted_offsets or ordered_offsets and (re-)add a field_offset method.

[ahicks92]

Should I just make it private and have field_offset and num_fields functions?

[eddyb]

That sounds okay - but is it really necessary to have the offsets permuted?

[arthurprs]

Sub. I'm sure we're gonna see some interesting stuff in the crater run, hopefully all fixable with a #[repr(C)]

[ahicks92]

@arthurprs
Yes, probably. But since the compiler isn't, well, compiling at the moment...

I'm waiting on #36622 at the moment. Then we shall see. Probably that can be worked around, but I don't have enough experience yet to know what I should or shouldn't be logging and also there's another project I can work on that's not Rust.

If you see places that still assume fields are in order, tell me. I'm more than willing to accept help finding them.

[alexcrichton]

ping @eddyb

Looks like some updates have happened since you last looked, want to take another peek?

[alexcrichton]

also tagging with relnotes for when this lands, seems like it could lead to some awesome benchmarks!

[ahicks92]

@alexcrichton
He knows, I'm still leaning on him incredibly heavily. There's bugs I don't trivially know how to fix blocking this moving forward. Sadly, this does not appear to be my ignorance: it is simply that complicated.

[alexcrichton]

Ah ok, no worries! Just checking up

[ahicks92]

All but 18 of the stage1-rpass tests now pass.

Debuginfo still needs conversion.

[petrochenkov]

Some thoughts (long term, no immediate action required):

It would be good to have two things related to field reordering:

• #[repr(rand)] - reorders struct fields pseudo-randomly, based on e.g. struct hash with some environmental variable used as salt. Can be used for fuzz testing to ensure code doesn't rely on field ordering. EDIT: I mean ability to set repr(rand) as a default layout for all structs, rather than a manually written attribute.
• #[repr(linear)] - Rust ABI but no field reordering. Fixed field order may be useful in code not related to C/FFI at all.

Also, reordering accidentally uses stable sorting algorithm now, just because sorting in libstd is stable.
I think it should be explicitly mentioned in comments (and eventually documented) that the field sorting algorithm is stable. There absolutely no reasons to reorder fields in (u8, u8, u8) and there certainly are reasons for (u8, u8, u8) to be layout compatible with [u8; 3] which is guaranteed to not be reordered.

[ahicks92]

@petrochenkov
Per rust-lang/rfcs#1582, there may be reasons to reorder (u8, u8, u8). No one has said that there are good reasons as of yet, but that PR does get into stuff to do with if/how tuple layout should be changed to support it.

I like the idea of #[repr(rand)], and there may even be a case for making this the default in debug builds; I think that a #[repr(linear)] deserves an RFC. The only use cases I can think of for the latter are some cases related to cache performance that may be handled better by other language extensions such as the ability to add empty padding to the end of structs and internal stdlib usage. I don't know enough about the cache performance use cases, however.

Both of these should be almost absurdly trivial to actually add. I could work out how to do it without leaning on @eddyb, I think.

[bors]

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

[eddyb]

The problem is that this function shouldn't be possible to call at all, this is really outlining, and there's no usefulness gained by having self - that is, I'd expect the Struct be created at the very end.

[eddyb]

This seems unnecessary, as a zero-length Vec is free.

[eddyb]

This can be written as let mut inverse_gep_index: Vec<u32> = (0..fields.len() as u32).collect();

[eddyb]

Also the same naming problem. laid_to_def_order might work? Still ugly.

[eddyb]

Is the usize type here necessary?

[eddyb]

Could you refer to "the definition" or "definition order" instead of "types"? That is, the order the fields come in is the source definition order, the types just happen to be associated with each field so the most straight-forward way to get them is in source definition order, but they're secondary to the order.

[eddyb]

"Maps from definition order to the order the fields were laid out in", maybe? Still not perfect though.
GEP should really not be mentioned if avoided. def_to_laid_order might work, although jarring.

[ahicks92]

I ended up calling these source order and memory order, I don't think there's anything better. The gep_index vec is now memory_index.

If there's better nomenclature, I don't know what it is.

[eddyb]

What if you make Struct::new take the Vec<Layout>? Maybe that way the double allocating can be avoided.

[eddyb]

Would sorting by descending alignment work in more cases than ascending?

[ahicks92]

To anyone watching, all the run-pass tests now pass.

[eddyb]

The layouts are interned so you can just use &'tcx [layout::Size].

[eddyb]

Still need to address this.

[eddyb]

Crater report has 3 legitimate regressions, one of them a LLVM assertion, the others are a bug with packed:

pubconstSIZEOF_QUERY:usize = 21;#[repr(C,packed)]pubstructp0f_api_query{pubmagic:u32,pubaddr_type:u8,pubaddr:[u8;16],}

The correct size is indeed 21, but this PR changes it to 24, presumably some logic went missing.

[bluss]

Will there be another repr attribute? Something like repr(C) but only to fix the field order and not care about the C part. Edit: Stupid me didn't see #[repr(linear)] was already mentioned.

[eddyb]

This can be written min_from_extern.unwrap_or(min_default).

[eddyb]

Should use | between these patterns to avoid repeating false (and true below).

[ahicks92]

I do not think this should be in the next beta, should the next beta be soon. I do not have the schedules memorized yet.

This code breaks other people's broken unsafe code in fun ways, but it may also break the compiler. I am not confident enough that this code doesn't create compiler bugs to wish to shove it into a beta as quickly as possible. If @eddyb or @nikomatsakis thinks we're fine, then go for it. But I'd hold off, just in case.

As for breaking unsafe code, there were at least 2 places in the compiler with missing repr(C). While one of these was tests, it does illustrate that people aren't immune to making this mistake. I think the test coverage probably covers enough that we don't have more of these in the compiler, however.

[alexcrichton]

To clarify, the 1.15 beta branch has not been forked off yet. That was scheduled to happen some time during the next week.

@camlorn is there perhaps a "boolean flag" style switch somewhere we could turn this optimization off on beta easily? If so we could leave this on master, easily backport a "turn off this optimization" to beta, and let this ride the trains to 1.16 stable.

[eddyb]

@alexcrichton There's a check for #[repr(C)] in librustc/ty/layout.rs, that can be hardcoded.

[alexcrichton]

Ok, so we have a few options now. I'm assuming that this PR itself is going into the 1.15 beta no matter what.

1. Do nothing and just send out a PSA
2. Leave this PR in tree, backport a change to librustc/ty/layout.rs to assume everything is #[repr(C)].
3. Revert this PR on beta

[ahicks92]

I can open another PR which just turns it off. All you have to do is short-circuit one condition in layout.rs.

[ahicks92]

I was wrong. Turning this off is a little complicated. If we do, some tests are going to fail, so we'll have to restore the old versions.

[nikomatsakis]

@camlorn can't we add a compiler flag (-Z reorder-layouts) and then pass this flag to the affected tests?

In retrospect I wish I had raised this to the core team to discuss proper handling.

[alexcrichton]

@camlorn it looks like this may have regressed a test on Windows AppVeyor, specifically:

[01:02:09] failures:
[01:02:09] [01:02:09] ---- [debuginfo-gdb] debuginfo-gdb\var-captured-in-sendable-closure.rs stdout ----
[01:02:09] NOTE: compiletest thinks it is using GDB without native rust support
[01:02:09] NOTE: compiletest thinks it is using GDB version 7009001
[01:02:09] [01:02:09] error: line not found in debugger output: $1 = 1
[01:02:09] status: exit code: 0
[01:02:09] command: PATH="C:\projects\rust\i686-pc-windows-gnu/stage2/lib/rustlib/i686-pc-windows-gnu/lib;C:\projects\rust\i686-pc-windows-gnu\stage2\bin;C:\projects\rust\i686-pc-windows-gnu\llvm\lib;C:\Python27;C:\projects\rust\mingw32\bin;C:\msys64\usr\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\7-Zip;C:\Program Files\Microsoft\Web Platform Installer;C:\Tools\GitVersion;C:\Tools\PsTools;C:\Program Files\Git LFS;C:\Program Files\Mercurial;C:\Program Files (x86)\Subversion\bin;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\Microsoft SQL Server\120\DTS\Binn;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio;C:\Program Files\Microsoft Windows Performance Toolkit;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit;C:\Tools\WebDriver;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.4;C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PrivateAssemblies;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI\wbin;C:\Ruby193\bin;C:\Tools\NUnit\bin;C:\Tools\xUnit;C:\Tools\MSpec;C:\Tools\Coverity\bin;C:\Program Files (x86)\CMake\bin;C:\go\bin;C:\Program Files\Java\jdk1.8.0\bin;C:\Python27;C:\Program Files\erl7.3\bin;C:\Program Files\nodejs;C:\Program Files (x86)\iojs;C:\Program Files\iojs;C:\Users\appveyor\AppData\Roaming\npm;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Program Files (x86)\MSBuild\14.0\Bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120;C:\Tools\NuGet;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files\Amazon\AWSCLI;C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\TShell\TShell;C:\Program Files\Microsoft DNX\Dnvm;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn;C:\Program Files\Git\cmd;C:\Program Files\Git\usr\bin;C:\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn;C:\Program Files\Microsoft SQL Server\130\DTS\Binn;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn;C:\Program Files (x86)\Apache\Maven\bin;C:\Program Files\LLVM\bin;C:\ProgramData\chocolatey\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Python27\Scripts;C:\Program Files (x86)\Yarn\bin;C:\Tools\NUnit3;C:\Program Files\dotnet;C:\Program Files (x86)\nodejs;C:\Users\appveyor\.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update2\bin;C:\Users\appveyor\AppData\Local\Yarn\.bin;C:\Users\appveyor\AppData\Roaming\npm;C:\Program Files\AppVeyor\BuildAgent;C:\projects\rust\sccache2" C:/projects/rust/mingw32/bin/gdb -quiet -batch -nx -command=i686-pc-windows-gnu/test/debuginfo-gdb\var-captured-in-sendable-closure.debugger.script
[01:02:09] stdout:
[01:02:09] ------------------------------------------
[01:02:09] GNU gdb (GDB) 7.9.1
[01:02:09] Copyright (C) 2015 Free Software Foundation, Inc.
[01:02:09] License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[01:02:09] This is free software: you are free to change and redistribute it.
[01:02:09] There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[01:02:09] and "show warranty" for details.
[01:02:09] This GDB was configured as "i686-w64-mingw32".
[01:02:09] Type "show configuration" for configuration details.
[01:02:09] For bug reporting instructions, please see:
[01:02:09] <http://www.gnu.org/software/gdb/bugs/>.
[01:02:09] Find the GDB manual and other documentation resources online at:
[01:02:09] <http://www.gnu.org/software/gdb/documentation/>.
[01:02:09] For help, type "help".
[01:02:09] Type "apropos word" to search for commands related to "word".
[01:02:09] Breakpoint 1 at 0x401bec: file C:/projects/rust/src/test/debuginfo/var-captured-in-sendable-closure.rs, line 66.
[01:02:09] Breakpoint 2 at 0x401c2a: file C:/projects/rust/src/test/debuginfo/var-captured-in-sendable-closure.rs, line 78.
[01:02:09] [New Thread 2696.0xb60]
[01:02:09] [01:02:09] Breakpoint 1, var_captured_in_sendable_closure::main::{{closure}} () at C:/projects/rust/src/test/debuginfo/var-captured-in-sendable-closure.rs:66
[01:02:09] 66 zzz(); // #break
[01:02:09] $1 = 0
[01:02:09] $2 = {a = 0, b = 4.420840408746224e-307, c = 5496392}
[01:02:09] $3 = 5
[01:02:09] [01:02:09] Breakpoint 2, var_captured_in_sendable_closure::main::{{closure}} () at C:/projects/rust/src/test/debuginfo/var-captured-in-sendable-closure.rs:78
[01:02:09] 78 zzz(); // #break
[01:02:09] $4 = 6
[01:02:09] [Inferior 1 (process 2696) exited normally]
[01:02:09] [01:02:09] ------------------------------------------
[01:02:09] stderr:
[01:02:09] ------------------------------------------
[01:02:09] warning: SHIMVIEW: ShimInfo(Complete)
[01:02:09] [01:02:09] [01:02:09] ------------------------------------------
[01:02:09] [01:02:09] thread '[debuginfo-gdb] debuginfo-gdb\var-captured-in-sendable-closure.rs' panicked at 'explicit panic', C:/projects/rust/src/tools/compiletest/src\runtest.rs:2407
[01:02:09] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:02:09] [01:02:09] [01:02:09] failures:
[01:02:09] [debuginfo-gdb] debuginfo-gdb\var-captured-in-sendable-closure.rs

That wouldn't happen to look familiar off-hand, would it?

[ahicks92]

@nikomatsakis
Only if they don't use stdlib. You could put repr(C) on them, though.
@alexcrichton
No, it wouldn't. Did anything merge after me which might potentially not be accounting for this change?

I'm going to see if I can figure out how to reproduce this locally.

[alexcrichton]

Ok turns out we're accidentally not running debuginfo tests on the bots. That may mean that this is trivially reproducible, though.

[ahicks92]

Upon following the readme's directions verbatim, I get this. Consequently, I can't reproduce. If I don't use rustbuild, it also happens, but later in the process.

I checked against WSL: the broken test passes there. Taking a cursory look at the test, I don't see anything that could be different based on platform. These are also both using gdb.

[gnzlbg]

@camlorn the WillOptimize1/2 tests cover structs and tuple structs, would it be possible to add tests that assert that the optimization triggers on enums and tuples as well? (or did I miss these tests somewhere?)

[ahicks92]

@gnzlbg
yeah, but I'll have to open a second PR for it at this point.

[gnzlbg]

@camlorn go for it, you already did the work, those are just the 3-5 easy lines of code to make sure nobody else screws it up, totally worth it

[ahicks92]

@gnzlbg
Yeah, but, we're turning this off temporarily. So it's pointless for the moment. I'll do it in the probably inevitable -z enable-field-reordering PR, though.

[bstrie]

What a pleasant surprise!

@camlorn Can you read over the comments in #28951 and confirm that this PR addresses any concerns that were raised there? If it does, can you give me the go-ahead to close it?