This should work around the problem:

private var results = (UInt32(0), UInt32(65536), UInt32(81920), UInt32(86016),
 UInt32(87040), UInt32(87296), UInt32(87360))

public func globalCellIndexB(forGridIndex i: UInt8) -> UInt32 {
 return withUnsafeBytes(of: &results) {
  $0.load(fromByteOffset: Int(i) &* 4, as: UInt32.self)
 }
}

@jckarter, @eeckstein I think the bug here is that the compiler does not optimize away copies of 'let' declarations (either local or global) that are initialized to a tuple of literals. This is basically because 'let's are rvalues and aren't naturally addressable. But I suspect an optimizer pass could identify the copy-from-constant-to-immutable-memory pattern and materialize the constant in read-only static memory instead.

It would be nice if there were a reliable way avoid the tuple copy even at -Onone.

@swift-ci create

@atrick I agree, this seems like a peephole we could add to LoadableByAddress, or its opaque value address lowering successor.

A better approach is to make a regular array lookup fast.
I added a optimization in #36439 which enables to compile

func globalCellIndexB(forGridIndex i: UInt8) -> UInt32 {
    return [UInt32(0), UInt32(65536), UInt32(81920), UInt32(86016),
                   UInt32(87040), UInt32(87296), UInt32(87360)][Int(i)]
}

to a zero-overhead table lookup.
Except the range check is done. But this makes sense - we want to have safety checks.

I don't think we will invest much effort to optimize the original tuple-pattern. I'm resolving this as done because the array-lookup code is the preferred way to go.