🚀 The feature, motivation and pitch

Currently, we have two layouts:

• FixedLayout
• FlexibleLayout

Where FixedLayout basically means "We already decided the layout, don't change it" while FlexibleLayout means "we are free to change this layout".

However, I think there are actually two different components of "decided this layout":

1. What is the output stride of this layout?
2. Who allocates the actual buffer for this tensor?

I believe conflating these causes some problems:

• For inductor template tuning, we care about the stride of the output layout, but we don't care who allocated the buffer (e.g. if it's just a view into a larger concat buffer). And Elias points out that he noticed this too here: Add support for cat memory planning mms with max autotune #132554 (comment)
• For Yifu's recent PR (Preliminary registered-buffer collective support via Inductor #138029), he cares about "who allocates the buffer for this layout", but he doesn't care about "what is the actual stride of this layout".

My proposal is that we scrap our current subclasses of Layout and refactor it into:

class Layout:
    stride: FlexibleStride or FixedStride
    allocator: NonOwningAllocator (view into another allocation) or Flexible or SymmMem

cc: @eellison @yifuwang @shunting314 @jansel

Alternatives

No response

Additional context

No response

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @kadeng @muchulee8 @amjames @aakhundov @coconutruben @jataylo @ezyang @yf225 @chenyang78 @ColinPeppler @desertfire