[TIR][Schedule] Transform layout #10538
Conversation
vinx13
requested review from
junrushao,
tqchen,
kparzysz-quic,
ZihengJiang,
masahi,
Hzfengsy,
comaniac,
jroesch,
areusch,
yzhliu,
merrymercy and
icemelon
as code owners
vinx13
force-pushed
the
feat/transform_layout
branch
from
fc3a9cc
to
b4f58df
Compare
vinx13
force-pushed
the
feat/transform_layout
branch
from
0e4ee24
to
d82bccf
Compare
| class BufferType(enum.IntEnum): | ||
| """Type of buffer in access regions of a block""" | ||
|
|
||
| READ = 0 | ||
| WRITE = 1 | ||
|
|
There was a problem hiding this comment.
@vinx13 Sorry I'm late and missed the code review. On this particular change, I'm 100% in favor of having enum type on C++ side; However, it could be more to "just use string" on the python side, i.e. use "read" and "write" to indicate BufferType. If you agree with my opinion, would you mind sending a quick patch? Thanks a lot!
There was a problem hiding this comment.
This sounds good to me as well, and would give the same readability benefits at the caller side. I kind of like the enum usage in python as well, since it lets the reader know what options are possible, but that's the less important benefit.
At some point, it would be nice to have a macro to define an enum in C++, along with its value/name mapping and an FFI interface, so that there would be a clear way to handle these.
* [TIR][Schedule] Transform layout * address commens * fix * doc * Address comments * remove unused * Use BufferIndexType enum * lint * support *args * lint * lint
…pache#10737) This is a follow-up of apache#10538 to use string instead of enum in python side.
This PR added a schedule primitive
transform_layoutin TIR. It is similar to the one in TE as discussed in RFC.cc @junrushao1994 @Lunderberg @jinhongyii @spectrometerHBH