From c8bb36c2a17f86f863946f5d359fcc9a49d17f1a Mon Sep 17 00:00:00 2001 From: Yuka Ikarashi Date: Tue, 5 Nov 2024 12:40:31 -0500 Subject: [PATCH] fix --- docs/Imports.md | 10 ++++------ docs/object_code.md | 40 ++++++++++++++++++++++++++++++++-------- 2 files changed, 36 insertions(+), 14 deletions(-) diff --git a/docs/Imports.md b/docs/Imports.md index 6bf3ad8d..61eed7f1 100644 --- a/docs/Imports.md +++ b/docs/Imports.md @@ -11,11 +11,9 @@ Therefore, if users wish to utilize Exo constructs, they must import them into t 2. [Core Exo Module](#2-core-exo-module) 3. [Memory Libraries](#3-memory-libraries) 4. [Instruction Libraries](#4-instruction-libraries) -5. [Frontend Syntax Utilities](#5-frontend-syntax-utilities) -6. [Standard Library Modules](#6-standard-library-modules) - - [6.1 Scheduling Utilities](#61-scheduling-utilities) - - [6.2 Standard Library Functions](#62-standard-library-functions) -7. [External Interfaces](#7-external-interfaces) +5. [Extern Libraries](#5-extern-libraries) +6. [Frontend Syntax Utilities](#6-frontend-syntax-utilities) +7. [Standard Library Scheduling Functions](#7-standard-library-scheduling-functions) 8. [API Cursors](#8-api-cursors) @@ -89,7 +87,7 @@ Alternatively, users can define their own scheduling operations by composing sch ## 8. API Cursors -Cursors (see [Cursors.md](./Cursors.md)) are Exo's reference mechanism that allows users to navigate and inspect object code. When users define new scheduling operators using Cursors, they may wish to write their own inspection pass (see [inspection.md](./inspection.md). API Cursors define types that will be useful for user inspection. +Cursors (see [Cursors.md](./Cursors.md)) are Exo's reference mechanism that allows users to navigate and inspect object code. When users define new scheduling operators using Cursors, they may wish to write their own inspection pass (see [inspection.md](./inspection.md)). API Cursors define types that will be useful for user inspection. ```python from exo.API_cursors import ForCursor, AssignCursor, InvalidCursor diff --git a/docs/object_code.md b/docs/object_code.md index 086f9198..44822069 100644 --- a/docs/object_code.md +++ b/docs/object_code.md @@ -31,15 +31,14 @@ def generic_conv1d( - [Annotations and Decorators](#annotations-and-decorators) - [`@proc` Decorator](#proc-decorator) - [Type and Memory Annotations](#type-and-memory-annotations) -- [Procedure Arguments](#procedure-arguments) -- [Variable Declarations](#variable-declarations) -- [Memory Spaces](#memory-spaces) + - [Procedure Arguments](#procedure-arguments) + - [Allocations](#allocations) + - [Memories](#memories) - [Loops](#loops) - [`for` Loop Syntax](#for-loop-syntax) - [Conditional Statements](#conditional-statements) -- [Operations and Assignments](#operations-and-assignments) +- [Assignments](#assignments) - [Understanding the Example](#understanding-the-example) -- [Conclusion](#conclusion) ## Annotations and Decorators @@ -67,7 +66,7 @@ name: type[size] @ memory - **`@ memory`**: The memory space where the variable resides. -#### Procedure Arguments +### Procedure Arguments Procedure arguments are declared with their types, sizes, and memory spaces. They can have sizes that depend on other arguments. @@ -145,7 +144,30 @@ foo(y[0:5], y[2:7]) This limitation exists because the analysis would be imprecise if we allowed such aliasing. This is similar to how C++ compilers can perform more optimization when you use the `__restrict__` keyword to explicitly indicate that you're not aliasing your buffers. -#### Allocations + +#### Passing Tensor Window Slices to Functions Expecting Non-Window Tensors + +It is not allowed to pass _window_ to a function that expects a non-window tensor as an argument. Consider the following example: + +```python +@proc +def callee(x: f32[10]): + pass + +@proc +def caller(x: f32[2, 10]): + callee(x[0]) # Error: Passing a window slice to a function expecting a non-window tensor + callee(x[1, :]) # Error: Passing a window slice to a function expecting a non-window tensor +``` + +In this code snippet, the `callee` function expects a non-window tensor `x` of shape `f32[10]`. However, in the `caller` function, we attempt to pass slices of the `x` tensor (`x[0]` and `x[1]`) to the `callee` function. These slices are windows of the original tensor, and passing them to a function expecting a non-window tensor is not allowed. + +To resolve this issue, you can either: +1. Modify the `callee` function to accept a window tensor as an argument, or +2. Create a new non-window tensor from the slice before passing it to the `callee` function. + + +### Allocations Variables within the procedure are declared similarly to arguments. @@ -159,12 +181,14 @@ y: i32 - **`i32`**: The data type (32-bit integer). - **No memory annotation**: Defaults to `DRAM` if memory is unspecified. -#### Memories +### Memories Memory annotations in Exo are used to model different hardware memory regions, such as DRAM, caches, or specialized memories. The `@` symbol is used to specify the memory space, for example: `@DRAM`, `@AVX2`, or `@Neon`. Memory annotations for your custom hardware accelerators can be defined externally to Exo and can be used as annotations in the same way. While Exo provides default memory (`DRAM`) and some library memory definitions for convenience (`AVX2`, `AVX512`, `Neon`, `GEMM_SCRATCH`, etc.), it is recommended and encouraged that users define their own memory annotations for their specific hardware. For more information on defining custom memory annotations, refer to [memories.md](./memories.md). + + ## Loops ### `for` Loop Syntax