pack Mappings of StringTableSlice better

StringTableSlice has an alignment of 2, given its u16 members.  The
byte_len field can always fit into a u8.  To give it an alignment of 1
so that it can pack well into a Mapping, we need to store the byte_start
member as separate u8 fields, and change Mapping's discriminant to a u8.

This change makes Range take up 12 bytes on a 64-bit system instead of
16, for a significant space savings.

LLVM ought to be able to optimize the load/load/shift/or recomposition
of byte_start into a single u16 load on unaligned architectures like
x86.  Current Rust does not do that, but an extra instruction or two is
worth a 25% space optimization.

Author: froydnj

idna/src/make_uts46_mapping_table.py

@@ -51,7 +51,13 @@ def strtab_slice(s):
         return c
 
 def rust_slice(s):
-    return "(StringTableSlice { byte_start: %d, byte_len: %d })" % s
+    start = s[0]
+    length = s[1]
+    start_lo = start & 0xff
+    start_hi = start >> 8
+    assert length <= 255
+    assert start_hi <= 255
+    return "(StringTableSlice { byte_start_lo: %d, byte_start_hi: %d, byte_len: %d })" % (start_lo, start_hi, length)
 
 ranges = []
 

idna/src/uts46.rs

@@ -21,17 +21,22 @@ include!("uts46_mapping_table.rs");
 
 #[derive(Debug)]
 struct StringTableSlice {
-    byte_start: u16,
-    byte_len: u16,
+    // Store these as separate fields so the structure will have an
+    // alignment of 1 and thus pack better into the Mapping enum, below.
+    byte_start_lo: u8,
+    byte_start_hi: u8,
+    byte_len: u8,
 }
 
 fn decode_slice(slice: &StringTableSlice) -> &'static str {
-    let start = slice.byte_start as usize;
+    let lo = slice.byte_start_lo as usize;
+    let hi = slice.byte_start_hi as usize;
+    let start = (hi << 8) | lo;
     let len = slice.byte_len as usize;
     &STRING_TABLE[start..(start + len)]
 }
 
-#[repr(u16)]
+#[repr(u8)]
 #[derive(Debug)]
 enum Mapping {
     Valid,