{
  "schemaVersion": 1,
  "id": "atlas-lesson-compiler-layout-lowering",
  "title": "Compiler layout, lowering and buffer planning",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Chooses memory organization and hardware operations that implement a tensor graph.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/compiler-layout-lowering/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Model–machine co-design",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "OpenXLA is a representative compiler route. Exact passes, emitter choices and executable formats depend on software revision and target architecture.\n\nThese are logical address and payload counts for a synthetic array. They exclude cache effects, allocator overhead and measured compiler/device performance.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/compiler-layout-lowering-2346e5cffdce248a.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#compiler-layout-lowering",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "40e429a918541223908fed6c352e3878722419ce70b20f03a7ed41962a213cde",
  "contentLength": 6980,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-compiler-layout-lowering.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-compiler-layout-lowering.md",
  "sections": [
    {
      "id": "section-1",
      "title": "Compiler layout, lowering and buffer planning",
      "start": 40,
      "end": 407
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 407,
      "end": 2373
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 2373,
      "end": 2401
    },
    {
      "id": "section-4",
      "title": "Dense stride mapping",
      "start": 2401,
      "end": 3194
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 3194,
      "end": 3801
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 3801,
      "end": 4260
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 4260,
      "end": 4533
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 4533,
      "end": 4691
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 4691,
      "end": 4720
    },
    {
      "id": "section-10",
      "title": "When can two temporary tensors safely share a buffer?",
      "start": 4720,
      "end": 5155
    },
    {
      "id": "section-11",
      "title": "What is the payload traffic for reading and writing six two-byte elements once during a transpose copy?",
      "start": 5155,
      "end": 5426
    },
    {
      "id": "section-12",
      "title": "Evidence and scope",
      "start": 5426,
      "end": 5902
    },
    {
      "id": "section-13",
      "title": "Sources",
      "start": 5902,
      "end": 6262
    },
    {
      "id": "section-14",
      "title": "Continue exploring",
      "start": 6262,
      "end": 6285
    },
    {
      "id": "section-15",
      "title": "Foundations",
      "start": 6285,
      "end": 6522
    },
    {
      "id": "section-16",
      "title": "Related lessons",
      "start": 6522,
      "end": 6980
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#compiler-layout-lowering"
    },
    {
      "title": "XLA:GPU Architecture Overview",
      "url": "https://openxla.org/xla/gpu_architecture"
    },
    {
      "title": "StableHLO specification",
      "url": "https://openxla.org/stablehlo/spec"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/compiler-layout-lowering-2346e5cffdce248a.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Model graph and tensor intermediate representation",
      "url": "https://semiaifoundry.com/learn/atlas/graph-tensor-ir/"
    },
    {
      "title": "Full memory hierarchy and input path",
      "url": "https://semiaifoundry.com/learn/atlas/memory-hierarchy-route/"
    },
    {
      "title": "Kernel tiling, fusion and operand reuse",
      "url": "https://semiaifoundry.com/learn/atlas/kernel-locality-fusion/"
    },
    {
      "title": "Quantization and numerical representation",
      "url": "https://semiaifoundry.com/learn/atlas/quantization/"
    },
    {
      "title": "Runtime, driver and device dispatch",
      "url": "https://semiaifoundry.com/learn/atlas/runtime-device-dispatch/"
    },
    {
      "title": "Sharded matrix multiplication and result ownership",
      "url": "https://semiaifoundry.com/learn/atlas/sharded-matmul-ownership/"
    }
  ],
  "recordHash": "90f231e4ee2fae32062a1406f7f86e0400375e7cc53f0e2909a79f8f86e40298",
  "contentFormat": "text/markdown",
  "content": "Model–machine co-design · Atlas v1.3.0\n\n# Compiler layout, lowering and buffer planning\n\nChooses memory organization and hardware operations that implement a tensor graph.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#compiler-layout-lowering)Software abstraction layers mapped to physical memory and compute\n\nLearning objectiveExplain how layout and buffer lifetime choices alter data movement.\n\n## The mechanism\n\nLowering makes an abstract tensor operation progressively more concrete. The compiler chooses layouts, partitions work, selects library calls or generated kernels and plans when storage can be reused. A transpose can sometimes be represented by changing indexing, while another consumer requires a physical data rearrangement. Tile shapes must fit local resources and supported arithmetic instructions. Quantized values additionally need scales, zero points or conversions preserved through transformations. OpenXLA’s GPU architecture documentation supplies one representative route. Compiler decisions therefore affect both arithmetic efficiency and bytes moved, and inspecting the optimized representation often explains a surprising performance result.\n\nA layout choice is meaningful when the indexed values, storage ownership and next consumer are named together. A transpose may be a view with changed strides or a materialized reorder; the latter consumes bytes and time that the former does not automatically incur. A schedule that improves locality must retain the operator’s axis semantics and account for any conversion needed by its consumer.\n\n1.  Select a physical layout compatible with the dominant consumers and the target memory transaction rules.\n2.  Partition large operations into legal tiles or shards and select the corresponding hardware or library path.\n3.  Insert materialized layout conversions only where indexing transformations cannot satisfy a consumer.\n4.  Assign storage according to tensor lifetimes, aliasing rules and the desired execution overlap.\n5.  Generate target code and inspect the plan for unnecessary copies, unsupported operations and excessive temporary allocation.\n6.  Logical coordinate-to-value meaning survives layout changes even when physical addresses differ.\n7.  The next consumer determines whether a strided view is acceptable or a contiguous materialization and synchronization are needed.\n\n## Science and assumptions\n\n### Dense stride mapping\n\n$$\n\\operatorname{address}(i,j)=\\mathrm{base}+s(i\\,\\mathrm{stride}_0+j\\,\\mathrm{stride}_1)\n$$\n\nThe element’s byte address is base address plus bytes per element times the sum of each logical index times its element stride.\n\nSymbols and units\n\naddress(i,j)\n\nByte address of the element at logical indices i,j\n\nbyte address\n\nbase\n\nByte address of the logical origin\n\nbyte address\n\ns\n\nBytes per element\n\nbytes/element\n\ni,j\n\nValid row/column indices\n\ninteger indices\n\nstride₀,stride₁\n\nElement offset per one-index step on each axis\n\nelements/index step\n\ns is bytes/element and strides count elements; the expression yields a byte address for logical indices i,j.\n\nAssumptions Dense strided storage with valid bounds; tiled or compressed layouts require a richer mapping.\n\n## Engineering example\n\nSynthetic 4×8 row-major tensor has strides (8,1). Swapping logical axes can produce an 8×4 view with strides (1,8), avoiding a copy until a consumer demands contiguous rows.\n\nA row-major 2×3 array \\[\\[1,2,3\\],\\[4,5,6\\]\\] has element strides (3,1). Its 3×2 transpose view uses strides (1,3) and logically yields \\[\\[1,4\\],\\[2,5\\],\\[3,6\\]\\]. A separate contiguous two-byte representation of that result contains 12 payload bytes. If it is materialized by reading and writing each value once, the chosen local memory boundary sees 24 payload bytes, not merely the 12-byte output size.\n\n## Distinctions and tradeoffs\n\nA transpose symbol does not always imply a full copy, while a mathematically simple operation can require substantial physical movement.\n\nA layout that favors one operator may require expensive conversion for the next; aggressive storage reuse can restrict overlap between otherwise independent operations.\n\nCompiler choices can turn an apparently small model edit into extra copies, recompilation or an unsupported slow path.\n\n## Specifications and interfaces\n\nLayout\n\nIndex-to-address mapping\n\nLogical dimensions and physical contiguous dimension can differ.\n\nBuffer lifetime\n\nProducer completion to final consumer\n\nStorage reuse requires non-overlapping live ranges or correct aliasing semantics.\n\n### Interfaces\n\nTyped graph Input\n\nTensor semantics, shapes and dependencies\n\nLowered executable plan Output\n\nLayouts, buffer assignments, kernels and calls\n\n## Check your understanding\n\n### When can two temporary tensors safely share a buffer?\n\n1.  When their required live ranges do not overlap under the execution schedule\n2.  Whenever their names are different\n3.  Only if all kernels run on the CPU\n\nAnswer and reasoning\n\nWhen their required live ranges do not overlap under the execution schedule\n\nThe memory may be reused after the last consumer has finished, subject to aliasing and asynchronous execution rules.\n\n### What is the payload traffic for reading and writing six two-byte elements once during a transpose copy?\n\n1.  12 bytes\n2.  24 bytes\n3.  Six bytes\n\nAnswer and reasoning\n\n24 bytes\n\nSix elements × two bytes × one read and one write is 24 payload bytes at that boundary.\n\n## Evidence and scope\n\nOpenXLA is a representative compiler route. Exact passes, emitter choices and executable formats depend on software revision and target architecture.\n\nThese are logical address and payload counts for a synthetic array. They exclude cache effects, allocator overhead and measured compiler/device performance.\n\nNo current calculator directly models this lesson’s main mechanism. Use the library for related bounds while retaining their stated omissions.\n\n## Sources\n\n-   [XLA:GPU Architecture Overview](https://openxla.org/xla/gpu_architecture)\n-   [StableHLO specification](https://openxla.org/stablehlo/spec)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/compiler-layout-lowering-2346e5cffdce248a.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Model graph and tensor intermediate representation](https://semiaifoundry.com/learn/atlas/graph-tensor-ir/)\n-   [Full memory hierarchy and input path](https://semiaifoundry.com/learn/atlas/memory-hierarchy-route/)\n\n### Related lessons\n\n-   [Kernel tiling, fusion and operand reuse](https://semiaifoundry.com/learn/atlas/kernel-locality-fusion/)\n-   [Quantization and numerical representation](https://semiaifoundry.com/learn/atlas/quantization/)\n-   [Runtime, driver and device dispatch](https://semiaifoundry.com/learn/atlas/runtime-device-dispatch/)\n-   [Sharded matrix multiplication and result ownership](https://semiaifoundry.com/learn/atlas/sharded-matmul-ownership/)"
}