struct field reordering and optimization #37429

ahicks92 · 2016-10-27T04:14:02Z

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 · 2016-10-27T04:16:31Z

src/librustc/ty/layout.rs

    }

-    /// Extend the Struct with more fields.
-    pub fn extend<I>(&mut self, dl: &TargetDataLayout,
+    fn fill_in_fields<I>(&mut self, dl: &TargetDataLayout,


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?

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.

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 · 2016-10-27T04:18:35Z

src/librustc/ty/layout.rs

+                        // We have to fix the last element of path here as only we know the right value.
+                        let mut i = *path.last().unwrap();
+                        i = st.field_index[i as usize];
+                        *path.last_mut().unwrap() = i;


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

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.

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

eddyb · 2016-10-27T04:20:02Z

src/librustc/ty/layout.rs

+                    let mut fields = fields.into_iter().map(|field| {
+                        field.layout(infcx)
+                    }).collect::<Vec<_>>();
+                    fields.insert(0, Ok(&discr));


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

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

eddyb · 2016-10-27T04:27:12Z

src/librustc/ty/layout.rs

@@ -511,41 +512,70 @@ pub struct Struct {
    /// If true, the size is exact, otherwise it's only a lower bound.
    pub sized: bool,

-    /// Offsets for the first byte of each field.
+    /// Offsets for the first byte of each field, ordered in increasing order.
+    /// The ith element of this vector is not always the ith field of the struct.
    /// FIXME(eddyb) use small vector optimization for the common case.
    pub offsets: Vec<Size>,


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.

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

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

arthurprs · 2016-10-28T12:16:00Z

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

ahicks92 · 2016-10-29T20:49:25Z

@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 · 2016-11-10T21:24:46Z

ping @eddyb

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

alexcrichton · 2016-11-10T21:25:33Z

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

ahicks92 · 2016-11-10T21:27:39Z

@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 · 2016-11-10T22:26:39Z

Ah ok, no worries! Just checking up

ahicks92 · 2016-11-11T23:14:39Z

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

Debuginfo still needs conversion.

petrochenkov · 2016-11-11T23:38:31Z

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 · 2016-11-12T07:22:38Z

@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 · 2016-11-13T02:55:28Z

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

eddyb · 2016-11-16T22:37:25Z

src/librustc/ty/layout.rs

    }

-    /// Extend the Struct with more fields.
-    pub fn extend<I>(&mut self, dl: &TargetDataLayout,
+    fn fill_in_fields<I>(&mut self, dl: &TargetDataLayout,


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 · 2016-11-16T22:37:43Z

src/librustc/ty/layout.rs

                     -> Result<(), LayoutError<'gcx>>
    where I: Iterator<Item=Result<&'a Layout, LayoutError<'gcx>>> {
-        self.offsets.reserve(fields.size_hint().0);
+        let fields = fields.collect::<Result<Vec<_>, LayoutError<'gcx>>>()?;
+        if fields.len() == 0 {return Ok(())};


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

eddyb · 2016-11-16T22:38:11Z

src/librustc/ty/layout.rs

+
+        self.offsets = vec![Size::from_bytes(0); fields.len()];
+        let mut inverse_gep_index: Vec<u32> = Vec::with_capacity(fields.len());
+        inverse_gep_index.extend(0..fields.len() as u32);


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

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

eddyb · 2016-11-16T22:38:42Z

src/librustc/ty/layout.rs

+        inverse_gep_index.extend(0..fields.len() as u32);
+
+        if repr == attr::ReprAny {
+            let start: usize = if is_enum_variant {1} else {0};


Is the usize type here necessary?

eddyb · 2016-11-16T22:47:57Z

src/librustc/ty/layout.rs

@@ -511,41 +512,76 @@ pub struct Struct {
    /// If true, the size is exact, otherwise it's only a lower bound.
    pub sized: bool,

-    /// Offsets for the first byte of each field.
+    /// Offsets for the first byte of each field, ordered to match the tys.


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 · 2016-11-16T22:51:40Z

src/librustc/ty/layout.rs

    /// FIXME(eddyb) use small vector optimization for the common case.
    pub offsets: Vec<Size>,

+    /// Maps field indices to GEP indices, depending how fields were permuted.


"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.

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 · 2016-11-16T23:11:34Z

src/librustc/ty/layout.rs

+                    }).collect::<Vec<_>>();
+                    fields.insert(0, Ok(&discr));
+                    let st = Struct::new(dl,
+                        fields.iter().cloned(),


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

eddyb · 2016-11-16T23:36:31Z

src/test/run-pass/nonzero-enum.rs

@@ -26,8 +26,9 @@ fn main() {
    assert_eq!(size_of::<E>(), 1);
    assert_eq!(size_of::<Option<E>>(), 1);
    assert_eq!(size_of::<Result<E, ()>>(), 1);
-    assert_eq!(size_of::<S>(), 4);
-    assert_eq!(size_of::<Option<S>>(), 4);
+    // The next asserts are correct given the currently dumb field reordering algorithm, which actually makes this struct larger.


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

ahicks92 · 2016-11-20T18:23:32Z

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

eddyb · 2016-11-21T01:13:58Z

src/librustc_trans/debuginfo/metadata.rs

@@ -1305,6 +1313,8 @@ impl<'tcx> EnumMemberDescriptionFactory<'tcx> {

 // Creates MemberDescriptions for the fields of a single enum variant.
 struct VariantMemberDescriptionFactory<'tcx> {
+    // Cloned from the layout::Struct describing the variant.
+    offsets: Vec<layout::Size>,


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

Still need to address this.

eddyb · 2016-11-23T03:54:47Z

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

pub const SIZEOF_QUERY:      usize = 21;

#[repr(C,packed)]
pub struct p0f_api_query {
	pub magic: u32,
	pub addr_type: u8,
	pub addr: [u8; 16],
}

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

bluss · 2016-11-23T14:02:18Z

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 · 2016-11-23T21:10:57Z

src/librustc/ty/layout.rs

-            }
+        }
+
+        let at_least = if let Some(i) = min_from_extern {


This can be written min_from_extern.unwrap_or(min_default).

eddyb · 2016-11-23T21:11:49Z

src/librustc/ty/layout.rs

+            can_optimize = !reprs.iter().any(|r| {
+                match *r {
+                    attr::ReprAny => false,
+                    attr::ReprInt(_) => false,


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

ahicks92 · 2016-12-18T17:33:25Z

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 · 2016-12-18T17:42:17Z

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 · 2016-12-18T17:48:59Z

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

alexcrichton · 2016-12-18T19:02:42Z

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.

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

ahicks92 · 2016-12-18T19:24:35Z

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

ahicks92 · 2016-12-18T20:12:51Z

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 · 2016-12-19T15:31:39Z

@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 · 2016-12-19T17:56:09Z

@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 · 2016-12-19T18:25:44Z

@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 · 2016-12-19T18:44:21Z

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

ahicks92 · 2016-12-19T22:59:57Z

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 · 2016-12-21T15:42:00Z

@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 · 2016-12-21T18:55:47Z

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

gnzlbg · 2016-12-21T23:16:49Z

@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 · 2016-12-22T15:22:11Z

@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 · 2016-12-22T16:21:28Z

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?

@nikomatsakis

Disable field reordering This was decided via IRC and needs a backport to beta. Basically, #37429 broke servo, and probably needs an announcement and opt-in flag. I didn't run all tests locally but think I've already reverted all the ones that need to be reverted. r? @nikomatsakis

rust-highfive assigned eddyb Oct 27, 2016

eddyb suggested changes Oct 27, 2016

View reviewed changes

ahicks92 force-pushed the univariant_layout_optimization branch from 472a158 to 9553ddd Compare October 27, 2016 20:44

ahicks92 force-pushed the univariant_layout_optimization branch from 9553ddd to af058d6 Compare November 7, 2016 23:40

alexcrichton added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. relnotes Marks issues that should be documented in the release notes of the next release. labels Nov 10, 2016

ahicks92 force-pushed the univariant_layout_optimization branch from 376ac0c to 408bed9 Compare November 12, 2016 19:52

ahicks92 force-pushed the univariant_layout_optimization branch from 408bed9 to a565851 Compare November 16, 2016 21:31

eddyb reviewed Nov 16, 2016

View reviewed changes

ahicks92 force-pushed the univariant_layout_optimization branch from 1fbefa0 to 825ec31 Compare November 20, 2016 19:42

eddyb reviewed Nov 21, 2016

View reviewed changes

ahicks92 force-pushed the univariant_layout_optimization branch 3 times, most recently from 9bf17ce to b0c6c53 Compare November 22, 2016 20:34

eddyb reviewed Nov 23, 2016

View reviewed changes

ahicks92 deleted the univariant_layout_optimization branch December 18, 2016 20:11

alexcrichton mentioned this pull request Dec 19, 2016

rustbuild: Run debuginfo tests by default #38471

Merged

ahicks92 mentioned this pull request Dec 20, 2016

small fix to closure debuginfo #38483

Merged

jdm mentioned this pull request Dec 20, 2016

Update Rust to 1.15.0-nightly (71c06a56a 2016-12-18) servo/servo#14633

Merged

ahicks92 mentioned this pull request Dec 21, 2016

Disable field reordering #38523

Merged

bstrie mentioned this pull request Dec 22, 2016

Randomize the ordering of struct fields when compiling in debug mode #38550

Open

Thinkofname mentioned this pull request Dec 22, 2016

Add missing #[repr(C)] to SDL_Keysym Rust-SDL2/rust-sdl2#579

Merged

ahicks92 mentioned this pull request Dec 23, 2016

Begin exercising rustc's right to reorder struct fields for optimal padding #28951

Closed

philipc mentioned this pull request Dec 29, 2016

Use repr(C) for all Pod types nrc/xmas-elf#34

Merged

alexcrichton mentioned this pull request Dec 30, 2016

Hang in utp-0.6.3 test suite in Rust 1.15 #38720

Closed

ahicks92 mentioned this pull request Dec 31, 2016

Update Readme Instructions for 32-bit MinGW Builds #38743

Closed

vincentdephily mentioned this pull request Oct 16, 2018

Documentation of std::mem::size_of confusingly only details the #[repr(C)] case #55115

Open

Dentrax mentioned this pull request May 24, 2022

proposal: cmd/compile: type layout optimization: apply struct field reordering during compile time for efficient memory alignment golang/go#53048

Closed

struct field reordering and optimization #37429

struct field reordering and optimization #37429

Conversation

ahicks92 commented Oct 27, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arthurprs commented Oct 28, 2016 • edited Loading

ahicks92 commented Oct 29, 2016

alexcrichton commented Nov 10, 2016

alexcrichton commented Nov 10, 2016

ahicks92 commented Nov 10, 2016

alexcrichton commented Nov 10, 2016

ahicks92 commented Nov 11, 2016

petrochenkov commented Nov 11, 2016 • edited Loading

ahicks92 commented Nov 12, 2016

bors commented Nov 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahicks92 commented Nov 20, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eddyb commented Nov 23, 2016

bluss commented Nov 23, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahicks92 commented Dec 18, 2016

alexcrichton commented Dec 18, 2016

eddyb commented Dec 18, 2016

alexcrichton commented Dec 18, 2016

ahicks92 commented Dec 18, 2016

ahicks92 commented Dec 18, 2016

nikomatsakis commented Dec 19, 2016

alexcrichton commented Dec 19, 2016

ahicks92 commented Dec 19, 2016

alexcrichton commented Dec 19, 2016

ahicks92 commented Dec 19, 2016

gnzlbg commented Dec 21, 2016 • edited Loading

ahicks92 commented Dec 21, 2016

gnzlbg commented Dec 21, 2016

ahicks92 commented Dec 22, 2016

bstrie commented Dec 22, 2016

arthurprs commented Oct 28, 2016 •

edited

Loading

petrochenkov commented Nov 11, 2016 •

edited

Loading

bluss commented Nov 23, 2016 •

edited

Loading

gnzlbg commented Dec 21, 2016 •

edited

Loading