Cursor API Step 1 #220

gilbo · 2022-07-23T01:29:40Z

This change switches over the entire scheduling API to use the

p = sched(p, ...)

convention instead of the

p = p.sched(...)

convention.

Additionally, the pattern arguments now accept either pattern strings or cursors. An API_Cursors.py wrapper for the internal cursors has been created, which are the standard for interface use now.

This PR does not resolve the problem of having cursor forwarding yet. That will be a "Cursor API Step 2" change in the future.
This PR has not yet made sure that any untested code is properly updated to use the new API conventions.
This PR makes some substantial cleanups to parts of the GEMMINI code, but is not a full cleanup of that code yet.
This PR will leave large chunks of code in API.py commented out but not deleted. This is intentional. It will help me more smoothly merge in other branches that have been on hold; it may help others merge any outstanding branches as well. In particular, I need this to help me merge in all of the yet-to-be-committed fixes to the program analyses.

yamaguchi1024 · 2022-07-25T22:05:26Z

We don't intend to expose @sched_op([GapCursorA]) decorators to users, right? I wonder if it should start with an underscore to ensure it's for internal use only. We have @proc and @instr() and users can reasonably mistaken that @sched_op is one of them.

src/exo/LoopIR_scheduling.py

yamaguchi1024 · 2022-07-25T22:12:04Z

src/exo/__init__.py

 from .configs import Config
 from .memory import Memory, DRAM
 from . import query_asts as QAST

+from . import stdlib


I am really not sure if it's a good idea to name our standard library stdlib. Maybe just primitives or ops ? That's more consistent with e.g., apps/ and platforms/, no?

The idea is that stdlib lives under exo (i.e. exo.stdlib) in the Python module namespace. Ultimately, I expect stdlib to hold things like "standard memories" excluding apps and platforms which are not part of the standard exo-lang distribution on PyPI. We can create a second PyPI distribution for things like platforms libraries.

Hmmm I think stdlib is not saying anything, shouldn't users be able to import DRAM etc. and all the scheduling primitives directly with from exo import * ? I just think exo.stdlib should be just as simple as exo. And we can have peripheral code such as builtins and platforms separately and be accessed with exo.builtins

So, there will be a lot of scheduling primitives, not all of which will be atomic (e.g. repeat) and I expect that list to grow somewhat. Generally I would expect from exo import * to get you things like proc that you'll need to use regularly, and then you may want to specifically bind the namespace of scheduling operations to a shorthand like S or XS (exo scheduling?) via

from exo.stdlib import scheduling as S

builtins may be worth having under exo directly instead of stdlib. I'm not sure. As far as platforms, that shouldn't even be under exo in the namespace at all, and ultimately shouldn't be packaged with exo-lang in PyPI. We can create a separate exo-lang-platforms package if we want to have standard "platform support" with lower guarantees of quality than the core exo-lang distribution.

Shouldn't it be exo.scheduling then? I'm not sure why having stdlib in the middle is useful

My reply to this got scrambled. My ultimate plan for this is to move most of the current contents of the exo directory into a subdirectory called something like compiler. At that point it may make sense to move scheduling to exo.scheduling and likewise for other submodules that we want users to import. However, right now, there would be no distinction between exo.scheduling and exo.LoopIR which definitely should not be imported by user code.

yamaguchi1024 · 2022-07-25T22:16:06Z

src/exo/internal_cursors.py

+    # Block-specific operations
+    # ------------------------------------------------------------------------ #
+
+    def expand(self, lo=None, hi=None):


I think it'll be useful if we can do a syntax sugar on this s.t.

c = cblock.next() cblock = cblock + c

Yes, there may be better choices. (I would use the union operator a | b for what you're suggesting, not +) This "expand" method is just there so I could solve one particular issue and move forward. Don't take it as a long term commitment for what the API should be.

Make sense. Shouldn't it be + because it's like expanding a list? union feels like unordered.

It's a join in an appropriate lattice of sequences really. For example, suppose I have cursors to two statements with another statement in between.

s1 <- c1 s2 s3 <- c2

The smallest block containing the two statements with cursors (s1 and s3) is a block of all 3 statements. That's neither a concatenation nor union. It's a join of "intervals."

yamaguchi1024 · 2022-07-25T22:19:07Z

src/exo/platforms/gemmini.py

@@ -2,143 +2,172 @@

 from exo import proc, instr, DRAM, config, QAST
 from exo.libs.memories import GEMM_SCRATCH, GEMM_ACCUM
+from exo.stdlib.scheduling import *


Gemmini changes are great, thank you for looking into this!
I'll ask Jennifer to test this on AWS before merging alongside with gemmini-rocc-tests stuff

gilbo · 2022-07-25T23:55:23Z

We don't intend to expose @sched_op([GapCursorA]) decorators to users, right? I wonder if it should start with an underscore to ensure it's for internal use only. We have @proc and @instr() and users can reasonably mistaken that @sched_op is one of them.

The scheduling operators are exposed in src/exo/stdlib/scheduling.py. This file should never be imported by user-code.

gilbo · 2022-07-28T18:52:35Z

We can change this eventually. Right now, I just wanted to separate it from the other things in `exo` which should not be included by user code.

…

On Jul 27, 2022, at 9:57 PM, Yuka Ikarashi ***@***.***> wrote: @yamaguchi1024 commented on this pull request. In src/exo/__init__.py <#220 (comment)>: > from .configs import Config from .memory import Memory, DRAM from . import query_asts as QAST +from . import stdlib Shouldn't it be exo.scheduling then? I'm not sure why having stdlib in the middle is useful — Reply to this email directly, view it on GitHub <#220 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKZHLFVZEBURNC3J6AQDN3VWIHJ7ANCNFSM54NFWK6A>. You are receiving this because you authored the thread.

yamaguchi1024 · 2022-07-29T07:19:09Z

tests/test_schedules.py

+                for k in seq(0, m):
+                    x[i, j, k] = A[i + j + k]
+
+    foo = divide_dim(foo, 'x', 1, 4)


What will happen if there are multiple 'x' buffers in this proc? It seems the API does not loop over multiple Syms?

All of the scheduling operations are now designed to apply exactly once. Handling multiple applications of a scheduling operation should now be handled using higher-order combinators. This will be even easier once step 2 of the API update is done, since then you can do something like p.find_all(pattern) to get a list of cursors, and then repeat an operation for each cursor in the list.

gilbo and others added 19 commits June 26, 2022 16:39

partial edits, for sharing design

ad17ece

made changes to cursor API draft

ba65db1

checking in more intermediary work

fd99e4d

got first scheduling operation switched over

cb540c8

missed checkins

333aad0

Merge branch 'master' into cursor-api

fc52e86

more partial updates to the API

6d915c3

Merge branch 'master' into cursor-api

184aa30

modified tests to run scheduling on platforms not supporting execution

876457e

Merge branch 'master' into cursor-api

7334c01

Merge branch 'master' into run-sched-tests-on-all-platforms

249f51e

merged test harness change

f0dceba

missed something in the compilation test

45a27c7

Merge branch 'run-sched-tests-on-all-platforms' into cursor-api

b154de1

more intermediate changes

dd94895

more intermediate updates to the API

26fcda4

Merge branch 'master' into cursor-api

8ecb315

fixed up new neon test

7daf06b

ready to submit pull request

4a639f4

gilbo requested review from yamaguchi1024 and alexreinking July 23, 2022 01:29

yamaguchi1024 reviewed Jul 25, 2022

View reviewed changes

src/exo/LoopIR_scheduling.py Show resolved Hide resolved

yamaguchi1024 reviewed Jul 25, 2022

View reviewed changes

src/exo/LoopIR_scheduling.py Show resolved Hide resolved

yamaguchi1024 reviewed Jul 25, 2022

View reviewed changes

gilbo added 2 commits July 26, 2022 20:35

updated x86-SGEMM to use new API

719b827

fixed up x86 convolution

13d3c99

gilbo added 3 commits July 28, 2022 16:50

added divide and multiply buffer dimensions

ffcbc8b

Neon example finally fixed up

595250a

Merge branch 'master' into cursor-api

d6a5a79

yamaguchi1024 reviewed Jul 29, 2022

View reviewed changes

yamaguchi1024 approved these changes Jul 29, 2022

View reviewed changes

gilbo merged commit d3adc77 into master Jul 29, 2022

gilbo deleted the cursor-api branch July 29, 2022 22:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cursor API Step 1 #220

Cursor API Step 1 #220

gilbo commented Jul 23, 2022

yamaguchi1024 commented Jul 25, 2022

yamaguchi1024 Jul 25, 2022

gilbo Jul 26, 2022

yamaguchi1024 Jul 26, 2022

gilbo Jul 28, 2022

gilbo Jul 28, 2022

yamaguchi1024 Jul 28, 2022

gilbo Jul 28, 2022

yamaguchi1024 Jul 25, 2022

gilbo Jul 26, 2022

yamaguchi1024 Jul 26, 2022

gilbo Jul 28, 2022

yamaguchi1024 Jul 25, 2022

gilbo commented Jul 25, 2022

gilbo commented Jul 28, 2022 via email

yamaguchi1024 Jul 29, 2022

gilbo Jul 29, 2022

Cursor API Step 1 #220

Cursor API Step 1 #220

Conversation

gilbo commented Jul 23, 2022

yamaguchi1024 commented Jul 25, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gilbo commented Jul 25, 2022

gilbo commented Jul 28, 2022 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment