netip.Addr features an Unmap() method returning the unwrapped IPv4 contained in an IPv4-mapped IPv6 address: from ::ffff:203.0.113.10 or ::ffff:cb00:710a, it returns 203.0.113.10.¹ There is no Map() or To6() method for the reverse direction. Such a method is trivial to implement, but Go maintainers have rejected it on the grounds that users should write netip.AddrFrom16(ip.As16()) and let the compiler optimize it.² Today, this pattern is eight times slower than a native method. How can we teach the compiler to optimize this sequence?

The alternatives
Hacking the Go compiler
- The hammer
- The screwdriver
Next steps

The alternatives

Let’s explore three ways to implement the map semantics for netip.Addr. My favorite is to add it to the Go standard library. Go maintainers prefer a small external helper chaining netip.AddrFrom16() and netip.Addr.As16(), hoping the compiler eventually optimizes it. The unsafe package opens a third path, with the same performance as the first solution.

Modifying the Go standard library

Internally, netip.Addr stores any IP address as a 128-bit value with an extra field z to encode the family and the zone:

type Addr struct {
    addr uint128
    z unique.Handle[addrDetail]
}

type addrDetail struct {
    isV6   bool   // IPv4 is false, IPv6 is true.
    zoneV6 string // != "" only if IsV6 is true.
}

var (
    z0    unique.Handle[addrDetail]
    z4    = unique.Make(addrDetail{})
    z6noz = unique.Make(addrDetail{isV6: true})
)

AddrFrom4() encodes an IPv4 address as an IPv4-mapped IPv6 address and sets z to the unique value z4:

// AddrFrom4 returns the address of the IPv4 address given by the bytes in addr.
func AddrFrom4(addr [4]byte) Addr {
    return Addr{
        addr: uint128{
            0,
            0xffff00000000 |
                uint64(addr[0])<<24 | uint64(addr[1])<<16 |
                uint64(addr[2])<<8 | uint64(addr[3])},
        z: z4,
    }
}

Unmap() turns an IPv4-mapped IPv6 address into an IPv4 address by setting the z field to z4:

func (ip Addr) Unmap() Addr {
    if ip.Is4In6() {
        ip.z = z4
    }
    return ip
}

Implementing the reverse direction inside the Go standard library is trivial: we set the z field to z6noz if the address is IPv4.

// To6 maps an IPv4 address to an IPv4-mapped IPv6 address. It returns an
// IPv6 address unmodified.
func (ip Addr) To6() Addr {
    if ip.Is4() {
        ip.z = z6noz
    }
    return ip
}

As a helper

We can’t access the z field from outside the net/netip package. Instead, we build a small helper around the netip.AddrFrom16(ip.As16()) pattern:

// AddrTo6 maps an IPv4 address to an IPv4-mapped IPv6 address. It returns an
// IPv6 address unmodified.
func AddrTo6(ip netip.Addr) netip.Addr {
    if ip.Is4() {
        ip = netip.AddrFrom16(ip.As16())
    }
    return ip
}

As an unsafe function

Another solution uses the unsafe package to alter the Addr struct through a proxy with the same memory layout:³

// addrProxy has the same memory layout as netip.Addr.
type addrProxy struct {
    addr [2]uint64      // netip.uint128
    z    unsafe.Pointer // unique.Handle[netip.addrDetail]
}

var (
    anyIPv6    = netip.IPv6Unspecified()
    netipZ6noz = (*addrProxy)(unsafe.Pointer(&anyIPv6)).z
)

// AddrTo6 maps an IPv4 address to an IPv4-mapped IPv6 address. It returns an
// IPv6 address unmodified.
func AddrTo6(ip netip.Addr) netip.Addr {
    if !ip.Is4() {
        return ip
    }
    (*addrProxy)(unsafe.Pointer(&ip)).z = netipZ6noz
    return ip
}

Benchmarks

On my computer, with Go 1.27.1, the standard library solution costs 0.88 ns per operation, while the solution favored by Go maintainers costs 7.14 ns. The unsafe solution matches the performance of the first one.

goos: linux
goarch: amd64
pkg: github.com/vincentbernat/go-netip-addrto6
cpu: AMD Ryzen 5 5600X 6-Core Processor
                   │     sec/op     │
AddrTo6/safe            7.137n ± 0%
AddrTo6/unsafe         0.8682n ± 2%
AddrTo6/builtin        0.8775n ± 2%

Assembly code

Let’s check the assembly code the compiler generates for each solution.⁴ The one built into the standard library looks like this:⁵

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ  net/netip·z4(SB), CX     ; check "z" if this is an IPv4 address
 JNE   end                      ; if not, stop here
 MOVQ  net/netip·z6noz(SB), CX  ; CX = netip.z6noz
end:
 RET
// return value = Addr{hi: AX, lo: BX, z: CX}

Go’s assembly language is not a direct representation of the underlying machine language: it operates on a semi-abstract instruction set derived from Plan 9’s assembler. It has four pseudo-registers: FP (frame pointer for function arguments), PC (program counter), SB (static base pointer for global symbols), and SP (stack pointer). It also has architecture-specific registers like AX, CX, DX, BX, SI, DI, and R8 to R15. Instructions storing data use their last argument as the destination. Instructions can carry an explicit size suffix: MOVB moves a byte, MOVW 16 bits, MOVL 32 bits, and MOVQ 64 bits. In the example above, the first instruction compares the 64-bit value z4 with the CX register.

The unsafe solution looks almost the same:

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ  net/netip·z4(SB), CX  ; check "z" if this is an IPv4 address
 JNE   end                   ; if not, stop here
 MOVQ  netipZ6noz(SB), CX    ; CX = netip.z6noz
end:
 RET
// return value = Addr{hi: AX, lo: BX, z: CX}

The helper solution has far more instructions. To understand why, let’s look at the code for As16() and AddrFrom16(). They are short enough for the compiler to inline them.

func (ip Addr) As16() (a16 [16]byte) {
    byteorder.BEPutUint64(a16[:8], ip.addr.hi)
    byteorder.BEPutUint64(a16[8:], ip.addr.lo)
    return a16
}

func AddrFrom16(addr [16]byte) Addr {
    return Addr{
        addr: uint128{
            byteorder.BEUint64(addr[:8]),
            byteorder.BEUint64(addr[8:]),
        },
        z: z6noz,
    }
}

We can already guess the pattern to optimize: the code packs the IP address into an array, copies it, then unpacks it. If we inline the Go code by hand, we get:

func AddrTo6(input netip.Addr) netip.Addr {
    if !input.Is4() {
        return input
    }

    var a16 [16]byte
    byteorder.BEPutUint64(a16[:8], input.addr.hi)
    byteorder.BEPutUint64(a16[8:], input.addr.lo)

    addr := a16

    var output netip.Addr
    output.addr.hi = byteorder.BEUint64(addr[:8])
    output.addr.lo = byteorder.BEUint64(addr[8:])
    output.z = netip.z6noz
    return output
}

As humans, we can mentally derive the optimized form:

func AddrTo6(input netip.Addr) netip.Addr {
    if !input.Is4() {
        return input
    }
    var output netip.Addr
    output.addr.hi = input.addr.hi
    output.addr.lo = input.addr.lo
    output.z = netip.z6noz
    return output
}

Unfortunately, as of Go 1.26.8, the compiler is not smart enough to do the same:

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
; Push the stack (32 bytes):
;    0(SP) addr netip.uint128
;   16(SP) a16 [16]byte
 PUSHQ   BP
 MOVQ    SP, BP
 SUBQ    $32, SP

 CMPQ    net/netip·z4(SB), CX  ; check "z" if this is an IPv4 address
 JNE     end                   ; if not, stop here

; Pack: byteorder.BEPutUint64(a16[:8], input.addr.hi)
;       byteorder.BEPutUint64(a16[8:], input.addr.lo)
 MOVBEQ  AX, net/netip·a16+16(SP)
 MOVBEQ  BX, net/netip·a16+24(SP)

; addr = a16, 16 bytes at once through the vector register X0
 MOVUPS  net/netip·a16+16(SP), X0
 MOVUPS  X0, net/netip·addr(SP)

; CX = netip.z6noz
 MOVQ    net/netip·z6noz(SB), CX
; Unpack: output.addr.hi = byteorder.BEUint64(addr[:8])
;         output.addr.lo = byteorder.BEUint64(addr[8:])
 MOVBEQ  net/netip·addr(SP), AX
 MOVBEQ  net/netip·addr+8(SP), BX

end:
 ADDQ    $32, SP
 POPQ    BP
 RET
// return value = Addr{hi: AX, lo: BX, z: CX}

The compiler does a decent job on the byte shuffling: the eight byte stores of BEPutUint64() become a single MOVBEQ, which stores a register byte-swapped. The eight byte loads of BEUint64() become a single MOVBEQ the other way round.⁶ Three groups of instructions remain: a pack, a copy, and an unpack.

Hacking the Go compiler

The Go compiler has several phases:

Parsing: The compiler tokenizes and parses the source code. It builds a syntax tree for each source file.
Type checking: The compiler maps each identifier to the object it denotes, folds constants, and infers the type of every expression.
IR construction: The compiler converts the syntax tree and its types into its own intermediate representation (IR). This process, called “noding,” goes through a serialization format named unified IR.
Middle end: The compiler performs several optimization passes on the IR, such as devirtualization, function call inlining, and escape analysis.
Walk: This phase runs two steps: order of evaluation decomposes complex statements into simpler ones, and desugaring transforms higher-level Go constructs, like switch or channels, into more primitive instructions or calls to the runtime.
Generic SSA: The compiler converts the IR into Static Single Assignment (SSA) form, a lower-level intermediate representation suited for machine-independent optimizations and rewrite rules.
Machine code generation: The compiler rewrites the SSA form into machine-specific variants, allocates registers, and applies more optimization passes. At the end, the assembler turns the generated instructions into machine code.

The hammer

My first idea is to replace occurrences of netip.AddrFrom16(ip.As16()) with netip.Addr{addr: ip.addr, z: netip.z6noz} as early as possible, during the “noding” process. Before that, the type checking phase prevents us from accessing unexported struct fields.

Go 1.27 introduced a convenient debug option to dump the IR of a function at interesting points during compilation:

$ GOTOOLCHAIN=go1.27.1 GOAMD64=v3 go build -a -gcflags="-d=astdump=AddrTo6Safe" .
Writing text ast output for AddrTo6Safe to AddrTo6Safe.ast
Writing html ast output for AddrTo6Safe to AddrTo6Safe.html
Writing html syntax output for AddrTo6Safe to AddrTo6Safe.syntax.html

In the HTML file, the first column shows the IR as it comes out of noding:

DCLFUNC addrto6.AddrTo6Safe ABI:ABIInternal FUNC-func(netip.Addr) netip.Addr
DCLFUNC-Dcl
. NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. NAME-addrto6.~r0 Class:PPARAMOUT Offset:0 OnStack netip.Addr
DCLFUNC-body
. IF # ipv6_safe.go:11:2
. IF-Cond
. . CALLFUNC bool
. . CALLFUNC-Fun
. . . METHEXPR addrto6.Is4 FUNC-func(netip.Addr) bool
. . . . TYPE netip.Addr Class:PEXTERN Offset:0 type netip.Addr
. . CALLFUNC-Args
. . . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. IF-Body
. . AS # ipv6_safe.go:12:6
. . . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. . . CALLFUNC netip.Addr
. . . CALLFUNC-Fun
. . . . NAME-netip.AddrFrom16 Class:PFUNC Offset:0 Used FUNC-func([16]byte) netip.Addr
. . . CALLFUNC-Args
. . . . CALLFUNC ARRAY-[16]byte
. . . . CALLFUNC-Fun
. . . . . METHEXPR addrto6.As16 FUNC-func(netip.Addr) [16]byte
. . . . . . TYPE netip.Addr Class:PEXTERN Offset:0 type netip.Addr
. . . . CALLFUNC-Args
. . . . . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. RETURN # ipv6_safe.go:14:2
. RETURN-Results
. . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr

In the body of the if statement, we spot the calls to the method netip.Addr.As16() and to the function netip.AddrFrom16(). Our goal is to patch them with a struct literal:

IF-Body
. AS # ipv6_safe.go:12:6
. . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. . STRUCTLIT netip.Addr
. . STRUCTLIT-List
. . . STRUCTKEY netip.addr
. . . . DOT netip.addr netip.uint128
. . . . . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. . . STRUCTKEY netip.z
. . . . NAME-netip.z6noz Class:PEXTERN Offset:0 unique.Handle[net/netip.addrDetail]

In noder’s reader.go, the expr() method builds the IR tree for an expression. At the end of the exprCall case, we add a call to a rewriteAddrFrom16As16() function. It takes the current node and returns the struct literal on success, or nil if the rewrite is not possible. First, we check that we have the expected pattern: a call to the netip.AddrFrom16() function with a call to the netip.Addr.As16() method as its only argument:

func rewriteAddrFrom16As16(n ir.Node) ir.Node {
    call, ok := n.(*ir.CallExpr)
    if !ok || call.Op() != ir.OCALLFUNC ||
        len(call.Args) != 1 || len(call.Init()) != 0 ||
        !isNetipFunc(call.Fun, "AddrFrom16") {
        return nil
    }
    inner, ok := call.Args[0].(*ir.CallExpr)
    if !ok || inner.Op() != ir.OCALLFUNC ||
        len(inner.Args) != 1 || len(inner.Init()) != 0 ||
        !isNetipFunc(inner.Fun, "Addr.As16") {
        return nil
    }
    x := inner.Args[0]
    // [...]
}

Then, we fetch netip.z6noz:

z6noz, err := lookupVar(ir.StaticCalleeName(call.Fun).Sym().Pkg, "z6noz")
if err != nil {
    return nil
}

And we build the struct literal:

typ := call.Type()
pos := call.Pos()
var list []ir.Node
for i, f := range typ.Fields() {
    var value ir.Node
    switch f.Sym.Name {
    case "addr":
        value = typecheck.DotField(pos, x, i)
    case "z":
        value = z6noz
    default:
        return nil
    }
    list = append(list, ir.NewStructKeyExpr(pos, f, value))
}
lit := ir.NewCompLitExpr(pos, ir.OSTRUCTLIT, typ, list)
lit.SetTypecheck(1)
return lit

Have a look at the complete patch.⁷ We can test it with the following commands:

$ cd src
$ ./make.bash
Building Go cmd/dist using /usr/lib/go-1.27. (go1.27.1 linux/amd64)
Building Go toolchain1 and bootstrap cmd/go (go_bootstrap) using /usr/lib/go-1.27.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 and commands using go_bootstrap and Go toolchain2.
Checking command staleness for linux/amd64.
---
Installed Go for linux/amd64 in /home/bernat/code/free/go
Installed commands in /home/bernat/code/free/go/bin
*** You need to add /home/bernat/code/free/go/bin to your PATH.
$ export PATH=$PWD/../bin:$PATH
$ go version
go version go1.28-devel_9834516e20 Sat Sep 12 08:23:11 2026 -0700 linux/amd64
$ go test net/netip/...
ok      net/netip   0.224s
$ cd ../../go-netip-addrto6
$ go test .
ok      github.com/vincentbernat/go-netip-addrto6   0.062s

The generated code for the helper is now the shortest possible version!

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ    net/netip·z4(SB), CX     ; check "z" if this is an IPv4 address
 JNE     end                      ; if not, stop here
 MOVQ    net/netip·z6noz(SB), CX  ; CX = netip.z6noz
end:
 RET
// return value = Addr{hi: AX, lo: BX, z: CX}

Go maintainers are unlikely to accept this change. It relies on the internal structure of net/netip.Addr. It’s an ugly hack in the noder, whose job is to faithfully translate the type-checked AST into the IR. And it’s harder to maintain than adding a To6() method.

The screwdriver

The right place for such an optimization is the generic SSA phase. One of the last machine-independent passes is memcombine. With the appropriate debug flag, the compiler dumps the SSA form after this pass:⁸

$ GOTOOLCHAIN=go1.26.8 GOAMD64=v3 \
> go build -a -gcflags='-d=ssa/memcombine/dump=AddrTo6Safe' .
$ head -5 AddrTo6Safe_01__memcombine.dump
AddrTo6Safe func(netip.Addr) netip.Addr
  b2:
    (?) v1 = InitMem <mem>
    (?) v2 = SP <uintptr>
    (?) v3 = SB <uintptr>

The result of the memcombine pass follows the same structure as the assembly code for AddrTo6Safe() we looked at earlier: two stores, one move, and two loads we would like to optimize away.

; […]
  v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
  v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
  v466 = ArgIntReg <*netip.addrDetail> {ip+16} [2]  ; input.z
; […]
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
  v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
  v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)

  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16

  v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
  v416 = Load <uint64> v285 v286                    ; addr[:8]
  v299 = Bswap64 <uint64> v416                      ; output.addr.hi
  v174 = Load <uint64> v415 v286                    ; addr[8:]
  v39  = Bswap64 <uint64> v174                      ; output.addr.lo
; […]

Each line features a value identifier (v442), an operation with its type (Bswap64 <uint64>), and its arguments (v490).⁹ Values are the basic building blocks of SSA and are defined exactly once. Square brackets enclose integer parameters ([8]) and curly braces contain auxiliary arguments ({netip.addr}). Operations writing to memory produce a new memory state. Every memory operation takes the current state as its last argument, which keeps them in order.

On paper

Let’s focus on output.addr.lo, aka v39:

  v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
  v174 = Load <uint64> v415 v286                    ; addr[8:]
  v39  = Bswap64 <uint64> v174                      ; output.addr.lo

To simplify this code, we could apply three rewriting rules:

The first one adds a shortcut when loading through a move: (Load (OffPtr [o] p) (Move p src mem)) => (Load (OffPtr [o] src) mem). This matches v174 with its arguments v415 and v286 and creates a new value v600:

  v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
  v600 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v174 = Load <uint64> v600 v282                    ; a16[8:]
  v39  = Bswap64 <uint64> v174                      ; output.addr.lo

The second one simplifies a load following a store: (Load p (Store p x _)) => x. The load is forwarded: the stored value replaces it and no memory access remains. It matches v174. It notices that v600 and v173 are the same address and replaces v174 with a copy of v442:

  v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
  v600 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v174 = Copy <uint64> v442                         ; bswap(input.addr.lo)
  v39  = Bswap64 <uint64> v174                      ; output.addr.lo

The last step cancels the two byte swaps: (Bswap64 (Bswap64 x)) => x. v39 becomes a copy of v490:

  v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
  v600 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v174 = Copy <uint64> v442                         ; bswap(input.addr.lo)
  v39  = Copy <uint64> v490                         ; output.addr.lo = input.addr.lo

If we ignore the values not needed to compute v39, only this SSA form remains:

  v490 = ArgIntReg <uint64> {ip+8} [1]  ; input.addr.lo
  v39  = Copy <uint64> v490             ; output.addr.lo = input.addr.lo

Let’s switch to output.addr.hi, aka v299:

  v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
  v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v416 = Load <uint64> v285 v286                    ; addr[:8]
  v299 = Bswap64 <uint64> v416                      ; output.addr.hi

To optimize it away, we also apply three rewriting rules:

The first one also adds a shortcut when loading through a move, but without an offset: (Load p (Move p src mem)) => (Load src mem). This rewrites v416 to use arguments from v286:

  v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
  v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v416 = Load <uint64> v22 v282                     ; a16[:8]
  v299 = Bswap64 <uint64> v416                      ; output.addr.hi

The second rule forwards a value stored one step earlier, skipping over a store to another address: (Load p (Store q _ (Store p x _))) => x. This matches v416: x is v542, p is v22 (&a16), q is v173 (&a16[8]), and p and q do not overlap for uint64.

  v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
  v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v416 = Copy <uint64> v542                         ; bswap(input.addr.hi)
  v299 = Bswap64 <uint64> v416                      ; output.addr.hi

The third rule cancels two byte swaps: (Bswap64 (Bswap64 x)) => x. v299 becomes a copy of v502:

  v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
  v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v416 = Copy <uint64> v542                         ; bswap(input.addr.hi)
  v299 = Copy <uint64> v502                         ; output.addr.hi = input.addr.hi

If we remove the values not used to compute v299, we get this SSA form:

  v502 = ArgIntReg <uint64> {ip+0} [0] ; input.addr.hi
  v299 = Copy <uint64> v502            ; output.addr.hi = input.addr.hi

In practice

Most of these rules already exist in generic.rules. They use conditions to validate their context: ssa.IsSamePtr() for the same address, ssa.Disjoint() for addresses that do not overlap. The rule forwarding a stored value to a load already exists with three variants looking through several other stores. Here are the two we need:

(Load <t1> p1 (Store {t2} p2 x _))
    && ssa.IsSamePtr(p1, p2)
    && copyCompatibleType(t1, x.Type)
    && t1.Size() == t2.Size()
    => x
(Load <t1> p1 (Store {t2} p2 _ (Store {t3} p3 x _)))
    && ssa.IsSamePtr(p1, p3)
    && copyCompatibleType(t1, x.Type)
    && t1.Size() == t3.Size()
    && ssa.Disjoint(p3, t3, p2, t2)
    => x

Go 1.27 added the rule loading through a move with CL 748200 to fix issue #77720:

(Load <t1> op1:(OffPtr [o1] p1) move:(Move [n] p2 src mem))
    && o1 >= 0 && o1+t1.Size() <= n && ssa.IsSamePtr(p1, p2)
    && !ssa.IsVolatile(src)
    => @move.Block (Load <t1> (OffPtr <op1.Type> [o1] src) mem)

It lacks a variant without an offset:

(Load <t1> p1 move:(Move [n] p2 src mem))
    && p1.Op != ssaop.OpOffPtr
    && t1.Size() <= n && ssa.IsSamePtr(p1, p2)
    && !ssa.IsVolatile(src)
    => @move.Block (Load <t1> (OffPtr <p1.Type> [0] src) mem)

There is no generic rule to cancel two byte swaps, but the AMD64 lowering pass includes this rule:

(BSWAP(Q|L) (BSWAP(Q|L) p)) => p

After switching to Go’s development branch and adding the missing rule, the generated assembly code is worse than with Go 1.26.8, even though our additional rule slightly improves the situation at the end:

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
; Push the stack (16 bytes):
;    0(SP) a16 [16]byte
 PUSHQ   BP
 MOVQ    SP, BP
 SUBQ    $16, SP

 CMPQ    net/netip·z4(SB), CX       ; check "z" if this is an IPv4 address
 JNE     end                        ; if not, stop here

; The four forwarded bytes: the low half of input.addr.lo is taken apart and
; put back together in registers
 MOVQ    BX, DX                     ; DX = input.addr.lo
 SHRQ    $24, BX                    ; BX = input.addr.lo >> 24
 MOVQ    DX, SI                     ; SI = input.addr.lo
 SHRQ    $16, DX                    ; DX = input.addr.lo >> 16
 MOVQ    SI, DI                     ; DI = input.addr.lo, kept for the pack
 SHRQ    $8, SI                     ; SI = input.addr.lo >> 8
 MOVBLZX DIB, R8                    ; R8 = byte(input.addr.lo)
 MOVBLZX SIB, SI                    ; SI = byte(input.addr.lo >> 8)
 SHLQ    $8, SI
 ORQ     R8, SI                     ; SI = two low bytes of input.addr.lo
 MOVBLZX DL, DX                     ; DX = byte(input.addr.lo >> 16)
 SHLQ    $16, DX
 ORQ     SI, DX
 MOVBLZX BL, BX                     ; BX = byte(input.addr.lo >> 24)
 SHLQ    $24, BX
 ORQ     DX, BX                     ; BX = input.addr.lo & 0xffffffff

; Pack: byteorder.BEPutUint64(a16[:8], input.addr.hi)
;       byteorder.BEPutUint64(a16[8:], input.addr.lo)
 MOVBEQ  AX, net/netip·a16(SP)
 MOVBEQ  DI, net/netip·a16+8(SP)

; The four other bytes of input.addr.lo, read one by one from a16
 MOVBLZX net/netip·a16+11(SP), DX   ; a16[11]
 SHLQ    $32, DX
 ORQ     DX, BX
 MOVBLZX net/netip·a16+10(SP), DX   ; a16[10]
 SHLQ    $40, DX
 ORQ     DX, BX
 MOVBLZX net/netip·a16+9(SP), DX    ; a16[9]
 SHLQ    $48, DX
 ORQ     DX, BX
 MOVBLZX net/netip·a16+8(SP), DX    ; a16[8]
 SHLQ    $56, DX

; output.z = netip.z6noz
 MOVQ    net/netip·z6noz(SB), CX
; output.addr.hi = byteorder.BEUint64(a16[:8])
 MOVBEQ  net/netip·a16(SP), AX
; output.addr.lo assembled from the previous steps
 ORQ     DX, BX

end:
 LEAVEQ
 RET
// return value = Addr{hi: AX, lo: BX, z: CX}

The rule loading through a move, added in Go 1.27, introduced this regression.

Out of order

Let’s not give up now! In reality, the rewriting rules run before memcombine, notably in the late opt pass. At this point, the inlined versions of BEPutUint64() and BEUint64() still expand to sixteen byte stores and sixteen byte loads, matching their source code:

func BEUint64(b []byte) uint64 {
    _ = b[7] // bounds check hint to compiler; see golang.org/issue/14808
    return uint64(b[7]) | uint64(b[6])<<8 | uint64(b[5])<<16 | uint64(b[4])<<24 |
        uint64(b[3])<<32 | uint64(b[2])<<40 | uint64(b[1])<<48 | uint64(b[0])<<56
}

Let’s follow two bytes of output.addr.lo: addr[15] and addr[11]. Here is a simplified SSA form before late opt:

  v273 = Trunc64to8 <byte> v490                     ; byte(input.addr.lo)
  v226 = Trunc64to8 <byte> v225                     ; byte(input.addr.lo >> 32)
; […]
  v235 = Store <mem> {byte} v233 v226 v223          ; a16[11] = byte(lo >> 32)
  v247 = Store <mem> {byte} v245 v238 v235          ; a16[12] = …
  v259 = Store <mem> {byte} v257 v250 v247          ; a16[13] = …
  v271 = Store <mem> {byte} v269 v262 v259          ; a16[14] = …
  v282 = Store <mem> {byte} v280 v273 v271          ; a16[15] = byte(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
; […]
  v433 = OffPtr <*byte> [15] v285                   ; &addr[15]
  v435 = Load <byte> v433 v286                      ; addr[15]
  v479 = OffPtr <*byte> [11] v285                   ; &addr[11]
  v481 = Load <byte> v479 v286                      ; addr[11]

The first rule loads through the move: (Load (OffPtr [o] p) (Move p src mem)) => (Load (OffPtr [o] src) mem). It matches both loads, which now read a16 with the memory state before the copy:

  v600 = OffPtr <*byte> [15] v22 ; &a16[15]
  v435 = Load <byte> v600 v282   ; a16[15]
  v601 = OffPtr <*byte> [11] v22 ; &a16[11]
  v481 = Load <byte> v601 v282   ; a16[11]

The second rule shortcuts a load following a store: (Load p (Store p x _)) => x. It matches v435, as v282 stores a16[15]. It does not match v481: v235 stores a16[11] four stores earlier in the chain, while the variants of this rule look through three stores at most.

  v435 = Copy <byte> v273        ; byte(input.addr.lo)
  v601 = OffPtr <*byte> [11] v22 ; &a16[11]
  v481 = Load <byte> v601 v282   ; a16[11]

The same happens to the other bytes: the rule forwards the four bytes stored last, a16[12] to a16[15]. The twelve other loads now read a16 instead of addr.

BEUint64() becomes a chain of Or64, each one adding a byte shifted into place. memcombine is a pass written in Go, not a set of rewrite rules. It starts from the last Or64 of the chain and collects up to eight terms. If each term is a byte load, extended to 64 bits and shifted, and if the eight loads read consecutive addresses from the same pointer with the same memory state, it replaces the whole chain with a single 64-bit load and a byte swap. Otherwise, it tries again with four, then two terms, and from each intermediate Or64. Here is the loop checking each term in a simplified version of combineLoads():

for i := int64(0); i < n; i++ {
    v := a[i]
    shift := int64(0)
    if v.Op == shiftOp {
        v, shift = peelShift(v)
    }
    if v.Op != extOp {
        return false
    }
    load := v.Args[0]
    if load.Op != ssaop.OpLoad {
        return false
    }
    if load.Args[1] != mem {
        return false
    }
    p, off := splitPtr(load.Args[0])
    if p != base {
        return false
    }
    r[i] = LoadRecord{load: load, offset: off, shift: shift}
}

For output.addr.hi, the eight loads read a16 with the same memory state v282:

  v13  = Load <byte> v22 v282               ; a16[0]
  v530 = Load <byte> v14 v282               ; a16[1]
  v488 = Load <byte> v504 v282              ; a16[2]
  v405 = Load <byte> v537 v282              ; a16[3]
  v385 = Load <byte> v397 v282              ; a16[4]
  v361 = Load <byte> v373 v282              ; a16[5]
  v196 = Load <byte> v63 v282               ; a16[6]
  v432 = Load <byte> v315 v282              ; a16[7]
  v319 = ZeroExt8to64 <uint64> v432         ; uint64(a16[7])
  v329 = ZeroExt8to64 <uint64> v196         ; uint64(a16[6])
  v330 = Lsh64x64 <uint64> [true] v329 v138 ; uint64(a16[6]) << 8
  v331 = Or64 <uint64> v319 v330            ; a16[7] | a16[6] << 8
; […] same for a16[5] to a16[1]
  v401 = ZeroExt8to64 <uint64> v13          ; uint64(a16[0])
  v402 = Lsh64x64 <uint64> [true] v401 v55  ; uint64(a16[0]) << 56
  v403 = Or64 <uint64> v402 v391            ; | a16[0] << 56 = output.addr.hi

memcombine merges them into one load and a swap:

  v286 = Load <uint64> v22 v282   ; a16[:8]
  v285 = Bswap64 <uint64> v286    ; output.addr.hi

For output.addr.lo, here is the chain memcombine sees after late opt:

  v436 = ZeroExt8to64 <uint64> v273 ; addr[15], forwarded
  v448 = Or64 <uint64> v436 v447    ; | addr[14] << 8, forwarded
  v460 = Or64 <uint64> v459 v448    ; | addr[13] << 16, forwarded
  v472 = Or64 <uint64> v471 v460    ; | addr[12] << 24, forwarded
  v484 = Or64 <uint64> v483 v472    ; | a16[11] << 32, loaded
  v496 = Or64 <uint64> v495 v484    ; | a16[10] << 40, loaded
  v508 = Or64 <uint64> v507 v496    ; | a16[9] << 48, loaded
  v520 = Or64 <uint64> v519 v508    ; | a16[8] << 56, loaded

From v520, four of the eight terms are forwarded bytes, not loads from memory, and memcombine can’t combine them. It doesn’t merge the four remaining loads either, as they sit on top of the forwarded bytes.

Back in order

In summary, the rewriting rules run too early to be effective. A quick workaround exists: run an earlier round of memcombine before late opt. After this change, the generated code for the helper is back to the shortest possible version:

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ    net/netip·z4(SB), CX     ; check "z" if this is an IPv4 address
 JNE     end                      ; if not, stop here
 MOVQ    net/netip·z6noz(SB), CX  ; CX = netip.z6noz
end:
 RET
// return value = Addr{hi: AX, lo: BX, z: CX}

And the benchmark confirms it! ✌️

goos: linux
goarch: amd64
pkg: github.com/vincentbernat/go-netip-addrto6
cpu: AMD Ryzen 5 5600X 6-Core Processor
                   │   Go 1.26.8    │             Our branch              │
                   │     sec/op     │    sec/op     vs base               │
AddrTo6/safe          6.5470n ±  0%   0.8944n ± 4%  -86.34% (p=0.002 n=6)
AddrTo6/unsafe        0.9071n ±  3%   0.8682n ± 1%   -4.28% (p=0.002 n=6)
AddrTo6/builtin       0.8871n ±  2%   0.8785n ± 1%        ~ (p=0.310 n=6)

Next steps

I think Go maintainers would reject this change because of the additional memcombine pass. Instead, I plan to publish this blog post and bring up the subject again as a follow-up to issue #54365. Either the sheer complexity and the Go 1.27 regression convince the maintainers that adding a To6() method is simpler and more efficient, or they advise me on how to move forward. Either way, digging into this subject taught me a lot about the Go compiler! ⚙️

Update (2026-10)

I opened issue #81994 to propose Addr.To6(). Give it a 👍 if you want it in Go!

IPv4-mapped IPv6 addresses let you handle only IPv6 addresses in your code and keep conversions at a few well-defined boundaries. I use them in Akvorado. ↩
This is not strictly equivalent. The zero value becomes :: while it would make more sense to leave it untouched. ↩
To avoid catastrophic bugs when netip.Addr’s layout changes, you must add tests to detect it. This is more dangerous if you put this code in a package. Either ask users to run the tests themselves, or detect the change at run time and panic. Hiding this optimization behind a build tag would make users aware of this potential trap. ↩
I produced the assembly code with GOTOOLCHAIN=go1.26.8 GOAMD64=v3 ./go-asm '\.asm' from the companion repository, then edited it a bit to keep this article from turning into an endless rabbit hole. Due to an unfortunate sequence of events, we switch between versions: Go 1.27 introduced a regression that blurs the point of this article. ↩
The function is short enough for the compiler to inline it, so the assembly code may vary depending on the surrounding code. ↩
MOVBEQ requires GOAMD64=v3, matching the x86-64-v3 microarchitecture from 2013. Otherwise, the compiler translates BEPutUint64() to BSWAPQ+MOVQ and BEUint64() to MOVQ+BSWAPQ. ↩
When the call is used as a statement, a struct literal alone is invalid. The patch then turns it into _ = netip.Addr{…}. ↩

The compiler can also write an HTML file with the result of each pass:

$ GOSSAFUNC=AddrTo6Safe \
> GOTOOLCHAIN=go1.26.8 \
> GOAMD64=v3 go build -a .
dumped SSA for AddrTo6Safe,1 to ./ssa.html

↩

Source line numbers in parentheses follow value identifiers, but I removed them from the examples. The SSA form also features branches, but we don’t need them to understand our optimizations. ↩

. . .

TRANSCRIPT:
Paul Krugman in Conversation with David Nir and G. Elliott Morris

(recorded 10/1/26)

Paul Krugman: Like almost everybody I know, I spend about 17 hours a day thinking about the midterms, and I’ve got G. Elliott Morris and David Nir from Strength in Numbers and The Downballot here to talk to me about: What do we know? What’s going to happen? What are the indicators? And then maybe some broader issues about what the heck we think is going on in U.S. politics. So, hi, guys. Welcome.

Elliott Morris: Hey, thanks, Paul.

David Nir: Paul, it’s a pleasure.

Krugman: So, yeah, as we record this, I guess it’s one month and two days before the midterms, and if I believe you guys, the polling and other indicators, which David will talk about, seem to be almost kind of shocking right now. Elliott, I just looked at your Fifty Plus One post, and I believe you now have 99% odds of Democrats controlling the House.

Morris: Yeah, well, it’s October, Paul. So we’re in what I consider spooky probability territory. 99% is when you start to go, “I hope these models are parameterized correctly.” Look, the way to unpack this: Our model at 50 Plus One shows a 99% chance that the Democrats will win 218 seats or more. 99% seems very large. As the forecaster, I don’t want to be wrong on the 99, but it makes sense when you look at the numbers on paper.

So, let’s take 2018 as a comparison case. That’s when Democrats won 235 seats in the House. That year, the generic ballot—which is a question that asks people how they will vote in their local congressional district, for which party they will vote—that has Democrats up somewhere between 8 and 9 points. Democrats won in 2018, leading the polls by about 8 or 9 points. They actually won the House popular vote by seven and a half points or so, if you account for some weirdness with, like, uncontested seats. So we are in a more favorable environment, if the polls are right, than 2018. And we also have a lot of other district-level indicators pointing the same way.

Krugman: But, I mean, the gerrymandering was fairly extreme before this, and if we go back to the beginning of this year, it was looking a little iffy, if I recall.

Morris: Yeah. So gerrymandering seems to have shifted maybe a handful of seats at most to the Republicans, accounting for some pretty rosy polling, for example, in South Texas and in Florida for the Democrats, where there’s been a larger shift than the national shift, which is about 10 or 11 percentage points. So if we are around eight points, our model says Democrats need to win the House popular vote by about three and a half points. So there’s room for the polls to be wrong by about five.

The average expected error for the polls at this point, 30 days before the election, is about three and a half percentage points. So we’re looking at a larger-than-average error in the polls. And then if you account for other indicators, district-level surveys, the race raters like we do, that’s how we get up to that 99. But yeah, I acknowledge this is a very, very large probability.

Nir: And Paul, just to address your point about the gerrymandering, which did heavily favor the GOP, it’s important to remember that Republicans were not doing that from a position of strength. They were doing it from a position of weakness, precisely because they knew that they were facing a very difficult midterm election. And they definitely—I can say this with certainty—definitely will not pick up, they will not flip, all of the seats that they targeted in Texas and Florida and elsewhere. And that has a lot to do with the quality of candidate recruitment on both sides.

And also, in particular in Texas and Florida as well, has a lot to do with Latino voters moving back against Trump after moving heavily for him in 2024. So, 2024 in a lot of ways was a high watermark. And so when you’re looking at how Trump performed in these districts two years ago, in a lot of cases, expect really a lot of fallback for the GOP.

Krugman: Tell me if I’m being underinformed here, but my understanding is that the gerrymandering was based, at least partially, on the assumption that the Hispanic shift towards Trump that took place in ‘24 was an enduring feature of the landscape, and that it all kind of goes wrong if, as now appears to be the case, it’s not enduring. Right?

Nir: That’s definitely what it appears to be. Because if you look at these redrawn districts, and instead of looking at how they went in 2024, if you go back a few years earlier and look at how they performed in 2020, when Joe Biden did much better with Latino voters than Kamala Harris did in many parts of the country, they show a much more competitive picture. And so you have Republicans talking about, you know, “Oh, these districts are Trump plus five, Trump plus ten, Trump plus 15.” But that’s 2024. You dial back to 2020, and suddenly we’re talking about districts that Joe Biden won, that Democrats have a real chance of holding on to in 2026.

Krugman: Okay. And I want to talk about other indicators, and polling in general. But just a question about the Senate: So now, we’re up into the 70s again for the Senate, right? And that’s a lot less. I mean, the Senate is sort of inherently gerrymandered. States that have about the population of some neighborhoods in the Bronx have as many seats as California. So, yeah. But that’s also looking pretty strong, right?

Morris: Well, speaking of state gerrymandering, don’t get me started about the drawing of the state border of Nevada. I mean, that was a gerrymander, right? So, look, the Democrats have 47 seats right now. They need 51 to have a majority and to overcome JD Vance’s tiebreaker as president of the Senate. So they need four pickups. They look likely, according to our model, to get a pickup in North Carolina, where the former governor, Roy Cooper, is running against the current chair of the Republican National Committee. So that’s what’s on my mind.

They look then likely as well to somewhere between a sort of toss-up and a lean Democratic seat in Texas and Ohio, where Democrats have got some good recruits in James Talarico and Sherrod Brown, a former incumbent senator of Ohio. And I should say Democrats are also very likely to hold on to their seat in Georgia, just for what it’s worth. And then we get into the seats that are, like, a lot, a lot tighter. That’s Iowa, currently Republican-held, but where the Democrat, Josh Turek, is leading the polls; Maine, where the polls were somewhat, you know, incredibly wrong in 2020, showing Susan Collins losing to—

Nir: Sarah Gideon.

Morris: See, this is why we do it together, Paul, right?

Krugman: Yeah, I know, it’s okay.

Morris: And then there’s Michigan, which seems like it should be a Democratic win in an environment where Democrats are ahead by eight points on the generic ballot. But the race is surprisingly close between Abdul El-Sayed and Mike Rogers. And there’s like a bunch of other reach seats that might be competitive. We can talk about Kansas, where Democrats currently have a polling deficit of under half a point in Kansas. Like, what’s the matter with Kansas?

Krugman: Yeah. I mean, objectively, Trump policies, especially a war that’s driven up diesel prices and fertilizer prices and all of that, has been really pretty bad for farm country. But I don’t know to what extent we’re seeing that, to what extent we’re just seeing really just bad Republican recruitment or just general Trump fatigue.

Morris: I’ll say one thing about the numbers and then hand it over to David. But the other Plains states—Nebraska, Iowa, and Kansas are the ones I’m thinking of—are all much more competitive than you would expect, given the fact that Donald Trump won these places by, you know, between 10 and 28 percentage points. I think in the case of Nebraska, if I’m remembering correctly. These are all within a point or so in the polls today, and back in 2025, when I was looking at Trump’s approval rating and all of the polling we do at Strength in Numbers.

So these are individual interviews from these Plains states. Donald Trump was also much less popular than you would expect, given his margins, and deportations and, and tariffs especially were very unpopular, or even more unpopular than Trump overall in these places. So, I think you’ve triangulated maybe there’s more economic pain in these places. Donald Trump has certainly very publicly pushed for these policies. So I can imagine voters are putting more blame on him directly because of the press conferences for tariffs in the early part of last year.

Nir: And Paul, I would say you’re exactly right to bring up diesel prices, because as bad as gas prices have gotten, you know, diesel has gotten much more expensive. And an attack on diesel prices is almost perfectly an attack on Trump’s base, because diesel is what’s used to carry goods in these Plains states that Elliott is talking about. It’s so important to the agricultural world, and Trump is really assaulting his own most loyal voters as hard as possible.

But it’s not just on that front, as Elliott said. You know, Republicans are upset about the stepped-up ICE raids in Kansas affecting the cattle industry. And so I think it’s just so many factors all combined together. You probably can’t pull just one out of them. And I think that they combine to make a lot of people feel like they’re just not being heard in general at all.

Krugman: Yeah. I mean, it’s one of those things where, for once, being an effete, liberal northeasterner makes me understate the amount of trouble that Trump is in, connected to diesel, because there’s not a whole lot of people driving tractors down the New Jersey Turnpike.

Nir: Not usually.

Krugman: But yeah, it’s actually kind of shocking to realize that gas sales are about two-thirds gasoline, one-third diesel, and the price of diesel is way up. So the actual pump shock out of the Iran war is more diesel than it is gasoline. And that’s hitting the states really hard.

One of the questions we all have now is, you know, polling. But David, you have this other indicator, which is kind of a cross-check on the polling, right? I want to hear about that, because I think it’s important.

Nir: It’s really fascinating, and I’m glad you brought it up. So at The Downballot, my colleague Daniel Donner published a new study recently, and we’re pretty sure that no one has actually looked at what Daniel looked at in precisely this way. So folks often ask, does turnout in primaries have anything to say about general elections? And they usually look at it on a state-by-state or case-by-case basis. Democrats, for instance, had incredibly strong turnout in the Texas primaries this year, better than Republicans, which is extremely unusual for Texas. So, does that actually mean anything for November? And when you look at these individual data points to compare primary turnout and general election performance, things kind of go all haywire.

But what Daniel did was he decided to look at primary turnout across the entire country. And he didn’t just do it for one year. He went back more than 100 years. And it turns out that there is a very close relationship in what we’re calling this national primary, when you add up primary votes for all 50 states, and then you look at the national House popular vote in the subsequent general election.

And what Daniel did, his real innovation here, it’s almost like he took the first derivative, because instead of looking at what primary turnout is in a given year, he looked at the change from midterm to midterm. And so if you look at the 2022 turnout, Democrats didn’t do particularly well that year. In fact, they are doing in 2026, 18 points better in this national primary that Dan essentially created synthetically. And what that extrapolates to, is that Democrats are looking like they’re doing 16 points better than in 2022, when you modify things a little bit, because, you know, Kamala Harris lost the popular vote in 2024.

But what this points to is a Democratic margin in the House popular vote of 13 points, which is considerably higher than what the current congressional ballot, the generic congressional ballot that Elliott was talking about, is pointing to. That’s around D+8. But what’s so important is that these metrics are all pointing in the same direction. And when we back-test this, when we look at how these perform historically, if these metrics are pointing in the same direction, then they tend to collectively be pretty accurate in predicting the House popular vote, which points to a real blowout for Democrats.

Krugman: I’m supposed to pretend to be objective and say “just the facts,” but actually I do care about how this election turns out. And what’s a little bit reassuring is these are actual votes. It’s sort of like the two things that we have that are actual votes, which are primary turnouts, and then special elections are not just based upon: Do people actually pick up the phone or actually respond online?

But how worried should we be? Response rates on polling are so low now, and how well are the pollsters managing to deal with this environment where people [are so overwhelmed with robocalls]? I think two-thirds of the time when my phone rings, it’s from my good friend, Spam Risk?

Nir: Hey, I’m buddies with them too.

Morris: Look, I really don’t have a whole lot of comfort for people who just want the polls to be right, because we just don’t know. Like, we just don’t know if the decisions pollsters are making to combat non-response bias—and I will define that—if their methodology, their decisions are right. Because, you know, the capital-P problem in polling is that the people that answer the phone are very often not like the people who don’t answer the phones. They’re not representative of the whole population.

That was true in 1936, the first big test of scientific polling, when there were too many high-income, Republican-leaning voters. It was the same case in 1948. It’s just been true for the entire history of this instrument. And pollsters have a lot of really fancy things they can do to try to make the poll look like the population in terms of demographics, because we do have a national poll funded by the U.S. government called the census every ten years. So we know how many white or Black or young or poor people there should be. We don’t know how many Democrats there should be in a poll, or how many Democratic voters for the upcoming election there should be, because that election hasn’t happened yet.

So we’re just left looking for signs that the polls are wrong. And I’ll say a couple words about that, and also just exploring what potential outcomes could happen given the fact that polls have been wrong before. That’s what our election forecast does. But the polls are +8 right now. As I said earlier, average error in the generic ballot is three points. Let’s simulate a lot of different elections given that distribution of error, the three-point standard deviation on error. What could that election look like? And we answer that question through the election forecast.

So then the thing that’s left is checking—checking the polling data. One thing we do at Strength in Numbers is to take a predictive model of how people voted in 2024, trained on 2024 data, not our current polling data, and predict the Democratic or Republican lean of the people who are actually answering our survey. And there’s some potential bias in that. But the trendline is really important, because if the types of people who are answering your poll in 2025, for example, look like a Donald Trump plus-one electorate based off of your predictive models, and then that drifts over time to be, you know, Harris +1, Harris +4, Harris +5, then you have some good indications that the types of people you’re getting are too Democratic. But we do not see that. It’s a totally flat line.

That’s one thing we’ve done. And there’s some other things we can do to look for red flags of non-response ahead of time, and basically they’re all fine right now. So I’m as confident as I ever am that the polls are right. I’m never really all that confident. That’s why we simulate the election.

Krugman: And in both your guys’ modeling, how much are you also doing fundamentals? For instance, state of the economy. And also, economic surveys, which may be less politicized.

Morris: The only fundamental that matters in a midterm election is the president’s approval rating. That might not be a fundamental for an economist. But historically, you know, growth in GDP, change in real disposable income, change in employment rate—these things have very little correlation to midterm election outcomes.

Krugman: Okay.

Morris: The only real structural factor is who’s the party in the White House. And to some extent, how many seats do they hold right now? There tends to be a slightly larger punishment historically when the party in the White House holds a bunch of seats. But that’s maybe a gerrymandering factor.

So, I do think the economic discontent in the country matters, but it is probably being proxied through the polling right now. It’s not the type of thing that is historically predictive of a midterm election in the way that these things are predictive of presidential elections.

Krugman: That’s interesting. I’ve been maybe a little off on that. I knew about the historically very strong predictive power of the economic variables, but for presidential elections. And so are you saying there’s no independent effect, or really just that it doesn’t help you at all with midterms, even if you didn’t have the polling?

Morris: Yeah. There’s a very weak correlation between some of these economic fundamentals and the outcome of the election. If you then look out of sample at your predictive accuracy of a model that is trained on previous elections using these fundamentals and test out-of-sample, it’s even worse. And yes, once you start accounting for some other factors, like literally not even the president’s approval rating, just which party’s in the White House, then any relationship totally falls away.

Krugman: Which does kind of raise a bit of a question, right? If you drop the presidential approval rating, then you still don’t get very much, right?

Morris: So, yeah, I mean, there is a positive correlation, but I think we’re looking at a +0.4 correlation here.

Krugman: Yeah. But then there are the obvious fundamentals: there’s the price of diesel, there’s just generally really bad vibes about the economy. But how do we reconcile that with the fact that the midterms look at this point so much like a blowout? What’s driving that?

Morris: Well, I think the economic discontent is a big part of the equation here. You know, Paul, we’ve talked about the “vibecession” on your podcast previously. So, there might be some other residual, just disapproval or poor rating on the economy that people map onto politics. Just because this isn’t a historical explanation for why midterms go the way they go doesn’t necessarily mean that it doesn’t matter this time around.

The thing I’ve identified in U.S. politics over the last year and a half of writing my Substack is just a very endemic, anti-status-quo, anti-incumbent bias. In our polling, like 70% of people say that they face significant hardship from inflation even this year. So I think these are all jumbled together.

Nir: And also we have seen some pretty remarkable correlations. In particular, when you drill down on Donald Trump’s approval rating about the economy and prices in general. Elliott, we have these wild graphs that when you look at Trump’s approval rating and overlay it with the change in gas prices and just shift it just by a couple of weeks, because the polls always lag a little bit, then they match up almost perfectly. Gas prices really do seem to dictate how people view Donald Trump’s success on prices. And so there’s no question that this anger is feeding into his low approval rating.

Krugman: During the Bush years we used to talk about that correlation a lot. And then, it seemed to go away. And now it’s kind of back. We used to say it was really terrible that so much seemed to depend upon gas prices over which the president really has no control. Which is not exactly true at this point, though, right?

Morris: Yeah. Historically I think that is right, yeah. This president has done a remarkable job of very publicly taking very unpopular stances on the policies that Americans notice the most, which is a very unique combination. And that might be the most simple explanation for why this midterm is going the way it looks like it’s going to go.

Krugman: Yeah. I mean, a couple of questions related to that. How much do you think Trump is paying a price for all of those extravagant promises he made in 2024? Do people remember that? It’s always a question in my mind. For political pundits, we’re always saying, “You said this, and now you say that.” But does the public have a memory of these things?

Morris: I don’t have any quantitative data on this, so I will get into anecdotal territory here. I watched a segment on CNN—yes, I do watch cable news sometimes—earlier this week, with a reporter just interviewing people at a gas station in Florida and interviewing former Trump voters. And there’s some sentiment of dissatisfaction. People say, “Oh, things aren’t going well.” And maybe two out of the ten people they interviewed said, “I feel betrayed.” Someone said “hoodwinked.”

So I think that is definitely an undercurrent we could identify, but it would be very hard, putting on my quantitative hat here, to identify how many voters the Republican Party has lost over the last year and a half due to Trump making such large promises. There’s definitely, in hindsight, I think for him, a bit of an own goal to be promising prices are going to go down on day one. But maybe he doesn’t actually care about the midterms or 2028. He just wanted to be president again, in which case maybe it was worth it for him.

Nir: And we’ve seen the same thing with his immigration enforcement policy. How many articles have we read featuring quotes from ordinary Americans, many of whom voted for Trump and said, “Oh, I voted for him to deport the violent criminals. I didn’t vote for him to deport the lovely fellow who’s been living and working in my community for 20 years,” and we might all smack our foreheads or get very angry about what feels like a lot of naivete about that.

But I am struck, even to this point, we’re now in October of 2026, how many times voters say, “This is what I thought Trump was going to do and he did X.” So two years later, people are still saying, yeah, “This was what we thought the promise was and he’s breaking it.”

Krugman: Yeah. Again, you guys are tracking this systematically. I’m not. But there does seem to be an abnormally large number of people willing to say, “I made a mistake in 2024.”

Morris: Yeah, about 15%, I believe, of Trump’s voters on average, according to some polls. A Navigator Research poll came out last month, in September, that showed 20% of Trump’s 2024 voters say they regret—they will agree with a poll question using the words “regret” their vote in the last election.

I don’t have comparable numbers, but just in absolute terms, if Donald Trump loses a quarter of his vote, or even if he loses a quarter of that 20%, then the 2024 election is like a Dukakis-style electoral defeat for the Republican Party in 2024. That’s a meaningful slice of the electorate, even 4 or 5%.

Krugman: I am still thinking about “vibecessions” and all of that stuff. And there’s one thing I noticed, and maybe it’s just one poll, but in the new AP-NORC poll, one of the things that was true consistently through the whole Biden era was that if you asked people, “How is the national economy doing?” they said, “Terrible.” You asked them, how is your local economy doing? And it was much better. And that gap is now gone.

It’s an interesting thing. I don’t know exactly where this fits in all this. But it is interesting that we’re no longer in a period where people are, you know, hearing bad stuff, but personally experiencing better stuff. Just generally, everyone is really pretty mad at the state of things now, which probably has something to do with all of these numbers. I think that was a complete non-sequitur given our previous conversation, but whatever.

Morris: No, I think there’s something to triangulate here. And in that same poll, I think Donald Trump’s approval rating on the economy among Republicans is at an all-time low in this new survey out this morning from AP-NORC.

But, I’ll back up from first principles here. Much of the conversation about the inflated or deflated consumer expectations and consumer sentiment over the past year has been about this idea that people are overindexing on the national economy, which may or may not be true. This survey seems to indicate maybe some movement towards convergence. If that’s the case, Republicans are, I hasten to say, dramatically more exposed to inflation in diesel and gas prices.

Krugman: Yeah.

Morris: And so I think we’re at the point in this cycle where after 15 months of inflationary statistics and inflationary news, Republican voters would be now coming around to the idea that this isn’t working out for them the way that they wanted.

In our Strength in Numbers September poll, we also found Trump at an all-time low approval among Republicans. So, our mental model is that maybe independents are super rational and everyone else isn’t. And so Democrats and Republicans wouldn’t be reacting to economic news as much as independents. That’s just the traditional understanding. So it would take a pretty cataclysmic-like event for Republican voters to then be saying, “I disapprove of this Republican president.” About 20, 25% of them do now. So I think these are all sort of related in my mind and my sort of mental model of voter psychology at this point.

Krugman: Okay. So backing up from there, we think we have a pretty good idea of what’s going to happen in the midterms, maybe—definitely in the House, and maybe the Senate—but Elliott, you’ve written a lot about this, and I think David as well—the extent to which people treated 2024 as a real seismic moment, defining a fact that American politics is never going to be the same. That’s really awesomely wrong, isn’t it?

Nir: Yeah. I mean, there’s this old saw in baseball that the good teams win close games, and that’s just not true. The good teams win blowouts, and the pundit class and so much of the media and frankly, a lot of politicians, including politicians in the Democratic Party, they failed to grasp that Trump won by one and a half points in 2024. That’s really about as close as it gets.

And I think that because the stakes of Trump winning felt so extreme and so dramatic, and you knew it was going to be so much worse than his first term, that kind of mentally or maybe even emotionally translated into something that felt like an absolute drubbing. But electorally, it simply wasn’t. And anyone at the time who was crowing about some Republican conservative era of cultural dominance, a massive sea change, wound up being wrong. And there were a lot of people who were saying, no, this is totally wrong. People like Elliott. Elliott was outspoken on this. He said it was a close election. It doesn’t mean what you think it means. And folks who hew to that view were totally vindicated.

Morris: Well, lo and behold.

You know, I actually give people a lot less credit than David did, given my previous employment situation. I think that there’s just an endemic bias in Washington, D.C. Well, there’s a couple of them. One is to make every story the biggest story. If you want to run like three or four days of TV coverage of Donald Trump because people are tuning in, you can’t just say, “Oh, he won a small election.” He has to have won a big election so that you can do that TV coverage that is performing well so you can justify seeking the ratings journalistically. I think that’s part of it.

And maybe you saw this in your past lives as well—a tendency for pundits to draw patterns out of one or two data points for the sake of narration. And I think that’s something that’s going on here, too. But I think the real meat of it was just that a lot of journalists write stories to seem smarter than everyone else. And one way to seem smarter than everyone else in Donald Trump’s victory is to just say that the liberal class of journalists were all wrong: “Look at this. Look at this huge victory. We now have to adapt to this new world we’re in where Donald Trump is winning huge victories so that we continue to not be—not be like a Democratic liberal herd.” That’s an instinct that is especially strong in the more rationalist, empirical publications, say, and I think it breeds a lot of bad storytelling.

The other thing that was a product of this was the constant humdrum about illiberalism on college campuses, starting in 2010 and right up to 2022, 2023. Well, what’s the real illiberalism on college campuses after 2025? What’s the real threat to free speech on college campuses after 2025? It’s probably not students preventing certain speakers from coming. It’s probably more the attacks on freedom of collegiate education writ large. So I think that that is another example of journalists missing the broader story going on for the sake of trying to appear smart to their peers.

Krugman: Yeah. When I was more part of the sort of conventional, journalistic milieu—which I never was very much, but somewhat—the idea was everything had to be counterintuitive. And then being against liberal pieties, and so precisely because Trump was so horrible from the point of view of any kind of conventional liberal perspective, therefore it seemed important to talk up how epoch-making and transformative he was. That was part of being counterintuitive.

And in some sense, the fact that somebody so self-evidently harmful to have won had to mean that there was something supernatural about his appeal, when in fact, the reality is that most normal people don’t actually pay that much attention.

Nir: You know, Paul, when I first started reading you, it was back when you were at Slate. And that reminds me of the infamous Slate pitch. Not that you were ever guilty of that, but the contrarian, counterintuitive, anti-liberal piety article that Slate made famous.

Krugman: Yeah, exactly. Most people won’t even remember, but the Slate pitch was, roughly speaking, “Here’s why running down cyclists is a good thing.”

Morris: It’s the “Um, actually...” article, right?

Krugman: Right, yeah.

Morris: And this goes back to that sort of anti-incumbency bias that stems from economic hardship. There’s just a tendency for voters to want to throw the bums out, to borrow that old phrase. There’s just an endemic negativity in the American public right now. And voters really want some big changes. I mean, in our survey, like 55% of voters every month—this percentage barely changes—say that major disruptive changes are needed to the nation’s political system and economy, whereas like 7% of people say things are going well for them. There is a middle option, for what it’s worth. But like those extremes, there’s a very wide imbalance in those extremes. And you would expect from that a tendency to punish the incumbent party, or pretty much whoever is in charge.

Paul, in one of our earlier conversations last year, we also talked a lot about the low-information voters who I know you’ve written about. This is a good part in our conversation to remind all the high-information listeners out there: Most Americans are not like us, not like you. About 50% of Americans say they do not get news on a weekly basis.

Krugman: Isn’t your definition of the information voter—you think it’s some kind of insult, but you just mean people who don’t know which party controls Congress, right?

Morris: Right. So this is sort of the low engagement voter. And then there is the actual low-information people, which is not really a putdown. Like we all have stuff going on. It takes a lot of energy to know what’s going on in politics.

On our survey only about 80% of people can say who controls both houses of Congress. We will be asking this question on a recurring basis in an upcoming project that is yet to be announced, a weekly survey at Strength in Numbers, which is exciting, and I imagine this number will be really helpful for us to track Democratic and Republican vote share, Trump approval and such by those voters who are or are not high or low information, or high or low engagement.

Those are the people who decide elections, and this is my broader point. Those are the people who decided the 2024 election: People who sort of remembered in the folds in their brain that things used to be better, so let’s go back to those things. Now, they’re in the sort of find-out stage of the F.A.F.O. And I think they will inevitably vote Democrats in charge and expect big changes.

And the three of us can probably forecast the number of major transformative changes that will come from Democratic Party leadership in Congress under the Donald Trump presidency, or even under a unified Congress in 2028, which is probably not a whole lot, let’s be honest. I imagine the American people will then punish the Democratic Party just as harshly.

Krugman: Yeah, well, certainly the next Democratic president, by inheriting reality, will simply be at a disadvantage.

I’m going to ask one last thing: the AI data centers. This is the political storm that I did not see coming. The apparent intensity of opposition is a surprise. And Trump—I’m sure that he has absolutely no idea about how the models work, but—

Morris: “Let data reign!”

He had a tweet where he said, “Let data reign,” right?

Krugman: Yeah, but is this going to matter? I’ve been seeing some people saying that at least in a couple of swing states, it might actually be an important factor.

Nir: I think so. Like you said, Paul, this issue almost feels like it came out of nowhere. The intensity of the anger. When you look at the polls now, I mean, huge majorities say that they oppose, for instance, building new hyperscale data centers in their neighborhoods or in their areas. And even six months ago, the numbers were much less opposed. And there is no question in my mind that so many voters are using this as an opportunity to take a stand against so many of the things that they don’t like: you know, the tech bro oligarchs, AI being shoved into every last corner of our lives. And these data centers are a stand-in for that.

And, boy, there have been so many ads run on them, Paul. And most of the ads are being run by Democrats. It is definitely one of the top issues that we are seeing coming up this year. It’s not just gas prices. It’s not just Trump’s mass deportation policy. Data centers are definitely playing a real role in some of these races. And what we’re going to see is a lot of races, especially governorships in Midwestern states that have leaned red in recent years, they’re probably going to be pretty close. And I think that when you’re on the wrong side of an issue like this, that you could lose a close race as a result.

I look at the example of Governor Greg Abbott, who has never had to sweat a general election. Now he’s running against Democrat Gina Hinojosa. Polls show it very, very close. And all of a sudden, Greg Abbott, this ultraconservative team-player guy for the MAGA movement, is coming out in favor of data center moratoriums and issuing executive orders to that effect. And so I think there’s no way he’d be doing that if he wasn’t afraid that this was a real issue that has lit a huge fire under voters.

Morris: I mean, he was approving the Starbase project for Sam Altman and Oracle, I believe in Texas, just this time last year. And now he says you have to go through “special approval,” which just means delays, right?

One place this might show up in our polling data from September is our question: which party do you think cares more about people like you? This was really bad for the Democrats in 2024, for example. Now they have a pretty large lead. About 38% of people say Democrats care more about them. 26% of people say the Republican Party cares more about them. It’s very interesting. There’s the next category of people, the 7% who say both parties care equally about them, and I guess people could be reading that as both parties care a lot about me, or neither party cares about me at all. 22% of people say neither party cares most about people like me. It’s kind of a comparative question. So maybe we’ll change that wording now that I’m thinking about it.

But I imagine getting up at his press conferences with the tech billionaires, hosting them at state dinners, tweeting—or I guess, truth posting via Truth Social? Truthing? Truthers? Yeah. Truthing that “Let data reign” comment and saying communities are going to be backwards if they reject data centers, it makes sense to me that they would say, “Oh, that guy, the Republican Party guy who’s on the wrong side of the biggest land use issue right now, which is dramatically unpopular—that party doesn’t care about me. Maybe the Democrats do now.” But there is a notable seesawing in that question across the elections, too. It just goes back to the sort of anti-incumbency undercurrent.

Nir: Yeah. And Elliott, I think, to that point, and Paul, getting back to what you said earlier about how the punditry just totally misunderstood 2024, how much talk did we see about polls showing that the Democratic Party’s brand was in poor shape? Those polls are absolutely true, and those voters’ feelings were absolutely understandable, but it simply missed the fact that people have to actually vote for one or the other. And even if they dislike both parties, these so-called double haters, they have to make a choice or stay home altogether.

And so I think ignore the polling on political parties’ standing and look at the polling of voter intentions. And that’s going to tell you a totally different story. People can still vote for Democrats even if they’re not happy with them.

Krugman: Yeah. Neither of you, happily for your own sanity, is in the business of modeling the mind of Donald Trump.

Morris: Thank God.

Krugman: But to choose this of all issues to really go on. I guess I thought maybe he doesn’t care at this point, but I would have thought that this would be a good time to pretend to be worried about data centers and AI and all of that.

Morris: Well, we have to consider maybe—I don’t want to do too much putting myself in the mind of Donald Trump because, oh, God. But we can think about the information environment he’s operating under, which is like the CNN headlines: about 99% of self-identified MAGA voters still approve of Donald Trump. You say, okay, well, that’s tautological. Whatever. He’s just insulated by these tech billionaires in and out of the White House. That’s practically his social circle at this point.

Nir: Right.

Morris: And then to the extent he gets information, it’s either fed to him by staffers who spend all day on X or Truth Social or whatever. Streaming news, or whatever cable news service currently exists for the right. But especially X, which is very endemic with super right-wing tech bros on there. I mean, Elon Musk being the number one example. If you’re operating any type of business and that’s the information environment you’re in, maybe you just don’t believe all the polls for the midterms. Maybe you don’t believe that people see these moves as unpopular.

Not to give him any credit, right? But I think the “X factor,” as David has called it, I believe, is a real problem in American politics. And you can see it operating chiefly in the chief executive.

Krugman: And there we are. Okay. Well, let’s hope that they’re in the bubble and we aren’t. Thanks a lot. And we’ll probably want to have a conversation after the midterms and figure out now what.

Morris: I’ll tell you if they happen.

Krugman: Yeah, if they happen.

Morris: That’s a joke. Hoping they happen.

Nir: Oh, Elliott! Don’t go there.

Morris: Okay, I’m kidding.

Krugman: No, I’m quite sure the elections will proceed. And then we’ll have a coup that will overturn it. But never mind. Sorry.

Nir: Guys! Let’s pull it together!

Krugman: Ok, ok. Well, thanks so much for speaking with me.

Morris: Always a pleasure.