Lunderberg commented on PR #77:
URL: https://github.com/apache/tvm-rfcs/pull/77#issuecomment-1165889831

   > Our design principle at TIR level ideally we start with one instance of 
possibility, then use probabilistic space of meta-schedule to represent 
multiple choices.
   
   For this, would the layout re-flowing occur periodically during 
optimization?  Otherwise, including transformations in the performance 
benchmarking of candidates would unfairly penalize candidates that add a 
transformation step, while excluding transformations would unfairly bias toward 
transformations, even when sequential operators require separate layout 
transformations.
   
   Representing different options as different allowed steps in a search space 
makes sense to me, so long as the candidates are reasonably exposed to 
optimizer.
   
   > In our particular example, however, the idea is that the schedule 
primitive do not modify the input/output buffer, but introduce preproc and 
postproc stages with clear hint that they should be lifted out (aka we are 
doing the same thing in two steps)
   
   I think I understand.  That would effectively be treating the 
preproc/postproc stages as separate function bodies, but ones which happen to 
exist within the same TIR PrimFunc for ease of use.
   
   With this representation, I think the biggest part would be determining when 
to fix a previously free parameter, in order to expose it as an assumption to 
another TIR PrimFunc.  Maybe in the "Step 2: Reflowing of Layouts", this isn't 
used to cancel any statements out, but instead to create a dynamic performance 
penalty if an assertion is no longer held, with the performance penalty equal 
to the time required to do the transformation.
   
   > As a quick intermediate middle ground. For most intermediate stage(really 
like add or exp), we would ideally not insert any layout decisions and allow 
decisions from other key ops(conv and matmul) to backprop their decision to 
them.
   
   I'd agree, though would phrase it somewhat differently.  The element-wise 
operations impose a constraint such that input and output layouts, that the 
input and output have identical layouts.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to